compiler
compiler copied to clipboard
elm-in-elm
meta-elm use cases
I am writing this up as an issue just because it seemed like a good place to write up something kind of long form. It's sort of an enhancement request, but I don't even want it to be as strongly worded as "request"; it's more just a data point.
So meta-elm is my project, and it's an expression evaluator for an AST that is similar in nature to elm-in-elm's AST. There's a pretty close-to-1:1 mapping between the two.
I have another project called mini-elm that uses elm-in-elm to parser Elm expressions and then hands off to meta-elm to parse them.
Right now meta-elm is strong in these areas:
- basic support for ints, floats, tuples
- full mapping of List.elm
- support for pipelines (foo |> bar |> baz)
It's also missing lots of very fundamental stuff like strings, records, custom types, etc. Also, it never intends to do things like parsing or deep type checking. For that it wants to play nice with elm-in-elm!
I know that elm-in-elm's evolution is gonna be driven 99.99% of the time by its own concerns, and not meta-elm. And of course that's reasonable. But to the extent I can influence things, here are my would-be-nice things:
- pipe operator (
|>): I would really like this! It just makes it a lot easier to write sample code. - basic arithmetic operators (+/-/*/div) - these would really make meta-elm feel "complete" for a subset of problems (manipulating lists of ints)
- Order support (EQ/LT/GE)
For meta-elm the only thing I care about at the moment is front-end parsing. So if I were king of the world, I'd say just parse |> and don't worry about de-sugaring it. (It might be good to have a dev process for that kinda stuff, anyway--be able to write parsers and have downstream stages just gracefully deal with "unknown" things--that probably already sorta happens?).
I am happy to elaborate on any of this in Discord; I just thought it's good to write it up here to avoid repeating myself.
