-
Notifications
You must be signed in to change notification settings - Fork 50
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
Merge DHExp and UExp #1197
Merge DHExp and UExp #1197
Conversation
The current branch also seems to not inherit bound names in stepped code / function output. E.g. in Cyrus's comment above you can see several . Additionally, see the screenshot: See (c119777) also for how this was extended to type functions. |
Ah yeah thanks @Crazycolorz5 - it was an issue with the transition rules for builtin application not using the evaluated version of the argument. |
@Negabinary couple of conflicts to resolve here |
@Negabinary looks like we've got quite a few merge conflicts here -- can you resolve those? |
Motivation:
Implements #878,
The advantages of merging DHExp and UExp are:
This pr replaces #931 which replaced #857. I have started again (using the previous iterations as inspiration) because the codebase has changed too much since those prs.
Key Changes
How to Merge with this PR:
If you used any dynamic expressions (DHExp) before the merge:
You will need to replace these with terms from TermBase.re. Most constructs retain the same name, the complication is that TermBase.re terms also have Ids. The following functions should help you add ids to terms:
|> Exp.fresh
,|> Pat.fresh
, or|> Typ.temp
to the end of the construct. (e.g.IntLit(4)
becomesInt(4) |> Exp.fresh
).Typ.temp
is preferred overTyp.fresh
because fresh generates new ids which can slow down type operations where types are often created then thrown out quickly. Ids are added to Typ.t values before they are printed to the screen.switch (exp)
will usually becomeswitch (exp.term)
. If you want to pattern match on a term and then wrap it back up with the same Id, you can useExp.unwrap
andrewrap
. (There are many examples of this in Term.re)If you have added any new constructs to DHExp:
If you have added any new constructs to TermBase.re that are removed at elaboration:
Since the pre- and post-elaboration data structures are the same, it's now preferred not to have elaboration remove constructs. (This also makes stepper traces more readable.) You might need to add transition rules and DHDoc_Exp rules for your new constructs.
If you have made any new "value" expressions:
I've tried to clarify how casting works in Unboxing.re. If you have a new value type, you might find it easier to write Transition.re rules if you add a new
unbox_request
constructor to Unboxing.re