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

Add support for constant patterns #1897

Merged
merged 1 commit into from
May 2, 2024
Merged

Add support for constant patterns #1897

merged 1 commit into from
May 2, 2024

Conversation

yannham
Copy link
Member

@yannham yannham commented Apr 25, 2024

This PR adds support for constant patterns, that is patterns matching specific booleans, strings, numbers or the null value. This allows to write for exampe:

match {
  "foo" => ...,
  "foo/bar" => ...,
  other => ...
}

Or

match {
  {enabled = true, ..rest} => code_path_when_enabled rest,
  {enabled = false, ..} => 'Error "Is not enabled!",
}

For destructuring, the semantics is the same as for enum tags - which are actually constants as well, but were just supported as a side effect of supporting eneral enum patterns - : a constant pattern forces the value and works as an assertion.

@github-actions github-actions bot temporarily deployed to pull request April 25, 2024 16:27 Inactive
This commit adds support for constant patterns, that is patterns
matching specific booleans, strings, numbers or the null value.
@yannham yannham marked this pull request as ready for review April 26, 2024 17:42
@yannham yannham force-pushed the feat/constant-patterns branch from 64100eb to 5c4ebad Compare April 26, 2024 17:42
@yannham yannham requested review from jneem and vkleen April 26, 2024 17:42
@github-actions github-actions bot temporarily deployed to pull request April 26, 2024 17:45 Inactive
impl CompilePart for ConstantPatternData {
fn compile_part(&self, value_id: LocIdent, bindings_id: LocIdent) -> RichTerm {
let compile_constant = |nickel_type: &str, value: Term| {
// if %typeof% value_id == '<nickel_type> && value_id == <value> then
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the type comparison an optimization? It looks to me like BinaryOp::Eq already handles mismatched types.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, it's because we can't compare functions. So we want to avoid this runtime error and eschew the comparison instead:

error: cannot compare values for equality
  ┌─ <repl-input-1>:1:1
  │
1 │ (fun _x => null) == (fun _x => null)
  │ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  │ │
  │ an argument has type Function, which cannot be compared for equality
  │ problematic argument evaluated to this

Since we have to do a pre-condition check anyway, instead of checking if one is a function, it's just simpler and probably faster to just avoid comparison for any value that doesn't have the expected type to begin with.

@yannham yannham added this pull request to the merge queue May 2, 2024
Merged via the queue into master with commit 3b01e62 May 2, 2024
5 checks passed
@yannham yannham deleted the feat/constant-patterns branch May 2, 2024 09:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants