RFC: Extend Lambda Representation with Metadata

[leostera]

Hello folks! 👋🏽

Hope this PR finds you well, I'm just here to ask a few questions since the code is not yet in a state where I'd ask for a proper review, but I still wanted to have some code to frame a portion of the discussion around a specific implementation approach.

By the end of last year, I started rewriting the Caramel compiler (an OCaml to Erlang copmiler) to target the Core Erlang language. This is essentially the Erlang VM's equivalent to OCaml Lambda.

In my effort to do this, I realized that it would be terribly simpler to just translate from OCaml Lambda rather than the Typedtree, but also that the Lambda language was missing several pieces of information that would be needed for me to build something that made any sense for the Erlang VM.

For example, variant constructors being replaced with integers doesn't help a lot in creating idiomatic Core Erlang, but passing around constructor metadata allows me to turn those integers into Erlang atoms instead. You could argue that the Erlang VM will turn those atoms into integers anyways, but the quality of life improvement of a pattern-match error on an 'None' is considerably better than just seeing a 0.

So I made some changes throughout the compiler to thread in metadata for the use-cases I needed and would like to request some comments from you on a few things.

1. Is this something that I could work on to upstream that would be welcomed into the compiler? -- there are several languages being built by forking off OCaml, that are struggling to keep up with the progress happening here. That effort could be spent in the main compiler instead. 4 examples right now are Melange, ReScript, Caramel, and Grain (although this one is primarily interested in the type-checker).

2. What would be an approach for adding metadata that would have the least impact on backends that do not need it? -- I opted for a naive extension of the lambda constructors with optional values, but perhaps this would lead to a lot of duplication when we are using the metadata. Perhaps it is okay to have a configurable flag to bypass adding the metadata everywhere, so it'll just be carrying around an additional None value.

3. Would it be interesting to extend the bytecode compiler to make use of this metadata somehow? -- For example, I can imagine Js_of_ocaml being able to use some of this data to provide more expressive errors.

4. Would it make sense to start with a small subset of the metadata and grow this on a need-basis or would you rather spend some time collecting all the metadata available first? -- the proposed subset is enough for my current needs for Caramel, but I can imagine extending it to support use-cases in Melange and ReScript, potentially helping those drop their forks entirely.

If the answers are that Yes, this is worth spending time on, and Yes, this is worth upstreaming, then I'd be thrilled to write a proper RFC and start porting this to trunk.

In any case, thanks for making an awesome language ❤️ and let me know what you think!

🙌🏽

/ Leandro