-
Notifications
You must be signed in to change notification settings - Fork 412
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
[do not merge] test branch for case/cond #8232
Conversation
Signed-off-by: Ali Caglayan <alizter@gmail.com>
Signed-off-by: Ali Caglayan <alizter@gmail.com>
Signed-off-by: Ali Caglayan <alizter@gmail.com>
We add a `(case ...)` constructor to dune_lang for actions which when expanded will reduce down to the matching branch. Signed-off-by: Ali Caglayan <alizter@gmail.com>
Signed-off-by: Ali Caglayan <alizter@gmail.com>
Signed-off-by: Ali Caglayan <alizter@gmail.com>
Thanks for sharing this. I'm thinking about whether it's possible to map package constraints to blang expressions so that conditional package actions can represented with cond. Take this opam file fragment as a motivating example:
The conditions are currently represented in dune with the The first constraint (
The second constraint ( It occurs to me that we already have logic for converting |
It is possible to add variables to the expander on the fly. This is how bindings for dependencies are done for example. It therefore shouldn't be a problem to define new variables and expand them in a blang. It's all up to the expander argument. Blang expansion happens in dune_rules in Blang_expand. |
I have one question regarding the fact that these forms are evaluated at parse time: is it possible to inspect the various branches in a static way? concretely I'm wondering if |
Having a look at the implementation of I think there might be a misconception with how pforms are expanded here however. Roughly it looks like:
What I was trying to say yesterday was that case/cond don't survive step 2. |
This is now in #8324 |
This is a test branch for case/cond so @gridbugs can work on top of. I will add these patches to #8229 in due time.