Merge DHExp and UExp

[Negabinary]

Motivation:

Implements #878,

The advantages of merging DHExp and UExp are:

• Removing duplication of code, making it easier & quicker to add new features to the Hazel language
• Consistency between evaluation results and written code - making easier to copy outputs into code, or to edit outputs, etc.
• Creating a consistency between the way static and dynamic code are pretty-printed, hopefully eventually replacing the pretty printer
• Tracing of ids through code allows us to correspond each construct from an output with the construct in the input

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

• DHExp is no longer a separate data structure to UExp.
• Fixpoints are now surfaced in user expressions
• Elaboration has been rewritten to more closely match elaboration rules from the POPL 2019 paper.
• Pattern matching has been rewritten to separate out an "unboxing" routine.
• Patterns can now have casts

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:

• When creating a new term add |> Exp.fresh, |> Pat.fresh, or |> Typ.temp to the end of the construct. (e.g. IntLit(4) becomes Int(4) |> Exp.fresh). Typ.temp is preferred over Typ.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.
• When pattern matching on a term, switch (exp) will usually become switch (exp.term). If you want to pattern match on a term and then wrap it back up with the same Id, you can use Exp.unwrap and rewrap. (There are many examples of this in Term.re)

If you have added any new constructs to DHExp:

• First, you'll need to make sure that there are constructs in TermBase.re that can store these dynamic expressions.
• Then you'll need to adapt your elaborator code to use only these constructs, and to make sure that all the types match up (we're no longer relying on statics information to provide types for elaboration.)

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

[Negabinary]

To your general questions, @disconcision

1. I've called TypeAnns casts because that data structure is both used for type annotation and pattern casts. The dream is to also eventually have expression annotations which pare the parallel for expressions using the cast data structure. When used for annotations, one of the arguments to a cast is always ignored.
   

2. Yes, DH is fully deprecated in Editor Componentization #1297 - the only reason we would keep the terminology is to make a distinction between expressions that have all their casts and expressions that have implicit recursion.

3. Yeah I think that's a valid observation, we possibly could have had a separate data structure just for the statics, but it might make it harder to share code between casting logic and statics code (not that I'm sure we do that much?). I also think I could have come up with some more consistent story for how ids flow through type checking, but I was lazy and just made them all new because I had no use for the type ids yet.

[cyrus-]

• Needs some conflicts resolved
• The polymorphism casting seems to have some issues (see Polymorphism under documentation):

[Crazycolorz5]

The casting in the documentation page seems to be an issue with -> associativity -- adding parens like so removes that:

However, after doing so, I do get an "InvalidBoxedIntLit" error, which I am now investigating.

[Crazycolorz5]

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.

[Crazycolorz5]

Seems to be not a polymorphism in particular. This is a minimal reproducible example. It seems to be an error in the term_of -- somehow the internal variable binding isn't being looked up?

[Negabinary]

Ah yeah thanks @Crazycolorz5 - it was an issue with the transition rules for builtin application not using the evaluated version of the argument.

[cyrus-]

@Negabinary couple of conflicts to resolve here