@chancyk: Thank you so much for your interest in this subject!
> I think fundamentally it (Elm - GBG) does two things nicely, concise ADTs and > a helpful compiler. > > ... (on the first feature, ADT's, with which I concur - GBG) > > The second nice feature is that the compiler is very helpful due to the sound > type system and the lack of type classes and metaprogramming, so the error > messages are always relevant. That's an interesting idea: that error messages are relevant due to lack of type classes, which I am not sure is true. Even if true, type classes (which I call "abilities" to disambiguate from OOP terms) help avoid a lot of boilerplate code, so it would be a trade-off. Adding "abilities" to the language isn't an essential addition for all the benefits of FP, as the language F# makes do with using qualifiers for common functions, just as (current version 0.19.x) Elm does, so if it turns out that having better error messages is deemed more important than avoiding boilerplate by offering a form of overloading functions that is compatible with full type inference, so be it. > I think having a language that's not self-hosted can be a feature... I've considered that, and while being able to self-host may mean possibly having to add some "unsafe" features to the language (possibly being enabled by a compiler switch) to be enclosed in an "unsafe" block, there are some benefits, both in ensuring that the language is "complete" in being a general purpose language, and in reducing time to compile the language from first pass times of many tens of minutes for the current Elm compiler written in Haskell to less than a second for generated C code. > I do wonder what something like Elm with nice escape hatches to something > like Nim would look like... I've pretty well dropped the idea of using Nim as a compilation target as it only offers `--mm:arc` and closures, anonymous functions, and nested function definition implementations that are needed at a cost of an extra dependency and compilation pass in "New -> Nim -> C" rather than "New -> C". As to what the language would look like, I've pretty much completed the design and it looks exactly like Elm code other than if one elects to use the added features of "abilities" to avoid some boilerplate code and having to qualify functions and some other considered features such as Higher Kinded Types and "RankNTypes"; most changes are "under the covers" and don't affect code, so much so that the new language should be almost fully backward compatible to Elm code (other than native code interfaces such as "ports") such that Elm libraries that don't use native code (libraries using native have been intentionally limited by Evan of Elm to only about ten) should be directly usable by the new language. There will be defined a few more "standard" modules that do use native code, such as implementing linear arrays and monadic chain mutation on these as per Haskell's `ST` monad (called the `Changing` type with the `AndThenable` = `Monad` ability in the new language) to be used when that data structure makes more sense in the interests of performance than current Elm's immutable data structures. There will also likely be available Haskell's `do` notation "sugaring" as applied only to `andThen`'s in the interests of ease of writing monadic chains, and a form of code generation macro definitions that will be more than C's preprocessor `#define`'s but less than Nim's AST macro's which open up a way to abuse in redefining the language. The one problem with "monadic" FP languages, as correctly identified in a post in this thread by @Araq, is monadic composition, but in a language with few monads/`AndThenable`'s as proposed here, almost all monadic chains will use only one of these throughout, so aren't so difficult to compose (and optimize such composition).
