-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
ISLE should have match
expressions
#5771
Comments
I think this is an interesting proposal, and could be nice to have! One observation that came up when we discussed this (and fleshes out your "partiality and side-effects" note) was that it's sort of a dual to An alternative that occurs to me now is that we could instead make the separation between pure LHS and impure RHS phases more flexible: one could continue to use pure ctors, and |
Yep, all very good points. But also I don't think we absolutely need to answer all those questions yet, since this is just syntactic sugar for something you can already write today. |
Ah, that's interesting; so the proposal is to actually desugar to a separate internally-generated helper term? That could work; it's potentially a little tricky both for plumbing reasons (sema-lowering an expression AST can now create new terms) and because one has to compute the closure-capture when defining the signature of that helper term (all used variable bindings need to be passed in). At that point it doesn't seem too much worse to natively represent a |
It's not exactly syntactic sugar unless you're proposing that match expressions make synthetic terms... (Oh, Chris beat me to this point.) I would want to take this new syntax as an opportunity to generate better code, anyway: the more we can fold into a single match tree, the more opportunities for sharing computations we'll find. This is a digression from the main issue, but I want to respond to one point: I think it's useful to maintain the current syntactic restriction that back-tracking can only occur due to failures on the LHS. It turns out we almost never use partial constructors on the RHS of a rule. As a data point, there are currently two instances across all backends:
It's easier to find these in ISLE's new codegen because now this is the only case where the generated code uses the |
Yes: when I want to match in an RHS, I am forced to make a synthetic term. I don't want to do that myself, since it is 100% mechanical. The compiler should do it for me. If, as an optimization, the compiler represents it some other way internally that is great, but irrelevant from a semantics POV. |
It's mechanical but it's not completely straightforward -- computing the captured closure to pass args to the synthetic term takes some semantic analysis, and splitting the match arms into separate rules is also the first time we have a "fork" in control flow. I'm not saying we shouldn't do it, but I guess my position is that it if the desugaring approach involves this significant additional complexity anyway, it might be worth thinking of doing it "the right way" from the start. |
If I want to match on something in an RHS, I have to split the continuation out into a new rule:
I wish that I didn't need to define a new term, and could instead match on
(a_to_b a)
directly insidefoo
:Some things to think about: partiality and side effects.
But since we can already write this today, just with two terms instead of one, I don't think we should have any show stoppers here.
The text was updated successfully, but these errors were encountered: