Although I have been thinking about the subject of this thread for some years, this thread is triggered by a presentation that Evan gave a few months ago, where along with analyzing the economics of funding new computer languages/projects, he reveals that he has been working on a language that has a C back-end that generates PostgreSQL tables and asks for input on what to do with this work.
SURMISED EVAN’s PROJECT
Given his background as Elm BDFL and functional language evangelist, we can surmise that the language resembles Elm and may be an adaptation of the Elm compiler written in Haskell and that, given Elm’s preparation for a reference counted memory management scheme in not allowing non-global cyclic references, it may use reference counting for memory management (or not, it doesn’t really matter), we kind of get an idea of what his demo project might be like. In his talk, he revealed that this project wouldn’t have some of the restrictions that Elm has as “decisions made about the Elm language are unique to what he sees as Elm requirements and aren’t necessarily as he would like to see general features” (paraphrased) and revealing that for a new language/project that the answer to general requests for features is generally “yes”.
WHERE DOES EVAN’S PROJECT GO?
Accordingly, I see that an Elm-like language could fill a more general set of needs, as follows:
- It would be backward compatible syntactically with current version 0.19.1 Elm so that all/most current Elm packages work with it other than the few “native” “elm” and “elm-explorations” ones that would be re-written to use C as its “native” back-end language.
- Versions of the equivalent to the VirtualDOM could be written for all major platforms to run under WebKit and thus support GUI’s for at least Windows, MacOS, Linux, Android, and IOS (as per the Rust Tauri project) and thus serve a role as does Google’s Flutter, and could also support CLI’s for all of the platforms that support them.
- Generating PostgreSQL tables would just be yet another package added to the new language’s ecosystem, and thus the new language could also fill that niche requirement.
- Some missing features such as full FFI could be added without breaking Elm syntax compatibility; as well, some desired features, although not strictly required, such as Higher Kinded Types (HKT’s) and some sort of type classes could be considered, which then would make it fairly easy to support something like ST modifiable linear arrays easily (although this last does not strictly require HKT’s and type classes).
- The first version would likely not be very sophisticated as to optimizations (as neither is Elm), but further refinements could include optimizations eliminating redundant reference counting by using data flow graphing (as do the languages Nim and Lobster), which can greatly speed up reference counting; as well, speed bottlenecks can be eliminated by using the common functional language programming techniques of function inlining, lambda “lifting”, phantom argument elimination, etc. to produce C-speed code.
- The result would be a pure functional language which is much easier to learn than Haskell (simpler stripped-down syntax and strict-by-default) while not having all the baggage of F# having to support DotNet with ancestry back to OCaml with a deterministic memory management system which could attain the speed of raw C code with the general safety of Rust without an obscure new syntax (just general functional programming as in ML languages).
WHERE DO WE GO?
Evan would likely be the best BDFL for such a project due to his Elm background, but if he doesn’t see it the way outlined above, then it could be forked away from Elm while still attempting to manage backward compatibility. If this new project adopted a new contributor-friendly policy (unlike Elm), I would happily be a contributor to the project. I am currently doing some work on an alternate to the self-hosting compiler library “Elm-in-Elm” project (which project I don’t see being completed anytime soon, given that it wants to do everything from scratch) and have translated large parts of the Elm compiler written in Haskell to Elm, with the parser completed, and I’m pretty much on top of the canonicalization, checking, optimization, and code generation phases, with not so much done on the type inference phase. This last phase likely requires the most work as it seems most non-trivial Elm compiler issues are related to type inference, I think possibly related to current Elm not unifying type variables from global scopes across nested local scopes.
Although a self hosting Elm-like compiler would be something nice to have, it isn’t absolutely necessary and just modifying the current Elm compiler written in Haskell starting with the back-end to generate C would also have the intended result.
WHO’S WITH ME?
Given that Elm hasn’t seen any releases for over four years now, even as to bug fixes, and loathe to see the incredible Elm functional syntax die or be relegated to only use in the current or expanded niche purposes, do any of you see things as outlined above or have further ideas to contribute. Even more specifically, if there were such an open source project, would any of you see yourselves as contributors or available to head the project?