Martin Janiczek

Very interesting, thanks for prototyping that @harrysarson ! How do you feel about it so far? (Let's take this to the Discord if you want.) I feel like we still...

Thanks @harrysarson for the experiment! Yeah we can always circle back to it :)

@tamagottschi what I read from this is that in addition to the AST, type inference and optimizations being exposed it would be good to have some kind of encoder /...

After talking in person at Elm Europe 2019, I understand this as: - parts of `elm-in-elm` would be reimplemented in `elmsl` in Rust itself (the parts that are missing in...

I believe it can be argued both ways. "type of the argument", "argument type" are what's meant in the current code. If we use "type argument", that's wrong for sure....

To be more precise, `VarName` is just a string, and there's eg. the distinction between `VarName` and `ModuleName`, even if both are just aliases to a string. The situation with...

Fair enough. I don't see a way from this other than `VarOrTypeName` which I think is pointless. Feel free to keep the current diff and change `String` into `VarName` in...

@harrysarson In an earlier version of this codebase I had `type ModuleName = ModuleName String` or some such. It worked, but I changed it to a simple `type alias ModuleName...

Hi @pablohirafuji, wow, thanks! I'll review this, hopefully this week. I'd also like to validate this approach with folks: * Aaron V. (how does elm-format solve this?) * Evan (is...

One of the feedback I've received is that `ParserWithState state a` is roughly equivalent to `Parser (a, state)`. We could use the `elm/parser` as-is and just track the state explicitly....