Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Add match #78

Closed
SheepTester opened this issue Mar 2, 2021 · 1 comment · Fixed by #104
Closed

Feature: Add match #78

SheepTester opened this issue Mar 2, 2021 · 1 comment · Fixed by #104
Labels
enhancement New feature or request

Comments

@SheepTester
Copy link
Member

Many good programming languages have something like match: Elm, Rust, Kotlin

match takes in a value and you specify different matching patterns; this is mainly used for enums but can also be used for matching strings and numbers.

An example with enums (in this case, the built in result type)

let wow: result[int, str] = ...
let lol: int = match wow {
  <ok number> -> number
  <err reason> -> len(reason)
}

An example with strings

print(match SystemIO.inp("Ask me a question.")! {
  "Who are you?" -> "I am an example."
  "How are you?" -> "I am good."
  "Why are you?" -> "Why are *you*?"
  _ -> "I don't understand."
})

Because match is an expression, it must return a value. Thus, a comprehensive check must be performed to ensure that every case is accounted for.

@SheepTester SheepTester added the enhancement New feature or request label Mar 2, 2021
@SheepTester
Copy link
Member Author

The use case of this is to map the ok type: mapOk : (a -> b) -> result[a, e] -> result[b, e].

Using if let will not work

let mapOk = [[a, b, e] transform: a -> b result: result[a, e]] -> result[b, e] {
  if let <ok aValue> = result {
    let bValue: b = transform(aValue)
    return ok(bValue)
  } else {
    return result
  }
}

because result is of type result[a, e], which is incompatible with result[b, e]. However, the type checker thinks that result could still be an ok even though that possibility was eliminated by the if let earlier.

We could make the type checker intelligent for if let and eliminate possible variants for enums somehow; however, this would be a pain because there's like three if-elses in scope.py (six in total).

Alternatively, we could add match, which would have to check that every possibility is accounted for, so we could instead do something like

let mapOk = [[a, b, e] transform: a -> b result: result[a, e]] -> result[b, e] {
  return match result {
    <ok aValue> -> ok(transform(bValue))
    <err reason> -> err(reason) // `err(reason)` will be type result[*, e] which is compatible with `result[b, e]`
  }
}

@SheepTester SheepTester added this to the N 1.3 milestone Mar 4, 2021
@Ashvin-Ranjan Ashvin-Ranjan linked a pull request May 18, 2021 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants