-
Notifications
You must be signed in to change notification settings - Fork 3
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
Allow extended pattern-matching for function arguments and let bindings #44
Comments
This seems like a worthwhile change outside of functions too: if we could make the left-hand side of a let binding be a pattern, instead of an identifier, we could then destruct data into multiple identifiers with one let, e.g.: let trans e (x1, _) =
let u~v = e in
let { a; b; c } = x1 in
if u = 0n then a + b else a + c |
Yeah, this is a nice QoL feature to have. I think we already allow this in let-statements, it just gets turned into a match statement during parsing. We could possibly implement it for function arguments by creating fresh variable for each argument pattern during parsing, then starting the body with a match to destruct it according to the user's pattern. |
From what I can see, this is only done for tuples in let statements right now. Parsing throws an error for both patterns above. That being said, I would think they would both be implementable using that desugaring approach you describe. |
Add an example network showcasing different let pattern sugar to implement in NV. Demonstrates work needed for #44.
Change the parsing rule for let patterns to include all possible patterns, all of which desugar using a match. This doesn't appear to break anything right now, although it conceivably *could*, so proceed with caution. Partially handles #44: for functions, we'll need to modify the component and fun expression parsing.
Would be nice to write e.g.
let trans _ x = x + 1
instead of having to declare an unused variable for the edge. It would also be easier to e.g. unpack tuples automatically.The text was updated successfully, but these errors were encountered: