Two weeks and 100 posts and @evancz never replied in a thread about him? That is just sad for the community 
4 Likes
Thanks for the summary on current Elm’s package system and limitations. I didn’t think of being dependent on GitHub’s hash algorithm. I suppose if ElmPlus used the same or a similar system and the hash algorithm changed and ElmPlus is an active project, it just means a rapid deployment of a new version that supports the new hashing algorithm, but if it happened to current Elm, it would be somewhat of a disaster, although one could download or clone the packages required and create a local cache based on them in an emergency such as this, given that Elm is so slow about updates/new releases.
F#/Fable supports different back-end languages by using a CLI option, which then automatically uses a different Sytem.Core package to link to by the different back-end code generators. Roc embeds the selection of the “platform” into the application source file. I think that the best was for ElmPlus would be to add some extensions to the project JSON file to specify the “platform”/“domain” (and perhaps optionally the back-end language), which then tells the compiler to automatically use the version of the core packages suitable to that “platform”/“domain” and output computer language source files. In this way, we can actually be completely backward compatible by allowing to link the the current Elm JavaScript core packages and work just as Elm does now, although with bug fixes and perhaps optional new features…
The was kind of the purpose of me starting this thread; to see if a response could be elicited from Evan…
From Evan’s GitHub history, the only recent contributions to the Elm compiler have been to make it easier to use npm to install Elm and to update the ability to use GHC Haskell 9.4 to compile the compiler from source; his other activity appears to all be to private repositories, and we can only guess what these might be related to but might be his new project to output PostgreSQL tables in C (or not…).
I think we are together in being grateful to Even in creating such a delightful language as Elm, the incredible amount of work he put into it initially in creating the compiler, core packages, and ecosystem, and in recognizing how talented a programmer he is. As well, I think we are together in that we would rather support him leading us into a new evolution of the Elm language if possible than breaking out on our own. However, in not getting a response from him, I think many of us are together in considering other options such as my proposal to build an “ElmPlus” language based on Elm.
Unfortunately, many talented people from the Elm community seem to have already moved on, many of them perhaps to Roc. However, in basing this new ElmPlus project on the existing Elm repositories, we may be able to shortcut the about six year history to this stage of Roc, which is nowhere near close to stable; While we need a few people that are Haskell-capable in order to be able to add a few new features to Elm and write different code generators for the back-end code generation, this need may disappear if we are successful in making the new compiler self hosting; what we do need are people capable of designing and building the ecosystem of the new language including the package management system, documentation, web page, editor plus-ins, with only a few able to contribute to the compiler effort and perhaps much of that only requiring proficiency in Elm. What we don’t need that Roc does is LLVM-IR experts, although we do need programmers capable of seeing how to make C run FP paradigms, but C-capable people are much more common.
In the absence of Evan, please join up, even if it is only to contribute ideas…
3 Likes
In the interests of avoiding :tumbleweed:, I think I need to get back to writing some code.
While waiting to see if others are successful in a project to convert the Elm compiler from Haskell to Elm, I think I’ll do some work using the current Elm source code in Haskell to eliminate some Haskell package dependencies and modularize some code that is unique to the requirements of Haskell (mostly UT8 string handling); as well, it would be good to try to fix the many pending issues at this stage so the new language can start from a clean slate. There are pending PR’s that may fix some of them that need to be reviewed as well…
1 Like
I guess you’re in the 3rd stage of grief. I’ve been there too, with Gren and PureScript. Now I’m in stage 5 thanks to F# 
This is true - I went over the Roc Zulip to ask some questions about the compiler implementations, and found quite a few ex-Elmers on there. I guess they were frustrated compiler geeks and found somewhere else to spend their excess productive energy…
However, Roc is still a new language and has a way to go to find its following and mindshare. If Elm were to move forward providing a path for its existing user base and with a plurality of contributors, I think it would easily make up lost ground and attract new talent.
Zokka is following the path of not extending Elm, just fixing things and improving the tooling - at least for now. I think that is the right direction for getting a community led version established.
4 Likes
I would go with Elm → MLIR → LLVM, if I were to do some compiler work. There is simply too much of a great and free and available now compiler infrastructure there to ignore. But yeah, its a bit of a learning curve for sure. MLIR is very well suited to optimising compilation of FP languages. This is another advantage to starting late - when Roc started, I don’t think MLIR existed yet. Its much harder to compiler FP straight to LLVM.
1 Like
Isn’t there an elm meetup coming up soon where Evan is going to talk?
1 Like
Now I’m in stage 5 thanks to F#
F#/Fable is indeed a very good alternative for Elm and I’m impressed by it as well for generating JavaScript.
However, your “stages of grief” assume that Elm is dead, and although it is faltering, I haven’t quite given up that it can be brought back to health in some form. It looks like there are efforts along those lines in the Zokka project, and although that is good as if successful it brings Elm back to health, I want something beyond Elm in a backwards-compatible Elm+ language that extends to more than just generating web pages. I am a FP evangelist that believes (and have proven at times with Haskell) that FP can be as fast as imperative languages…
1 Like
Thanks for twigging me to Zokka, I started to monitor this forum again after that thread and missed the announcement. It’s good to see its goals of just Elm that isn’t stagnant with bug fixes (at least for this year), but I wonder if it isn’t being too restrictive in the types of bugs that it isn’t fixing: specifically not fixed under this mandate is the bug where negative indices for integer case..of Int pattern matches aren’t accepted; This appears to be so that code generated using Zokka as the compiler is able to also be run using the current Elm compiler and thus use the Elm package library, but that would seem to unnecessarily restrict it. Still, at least somebody is working on something…
According to your link, we only have a week to wait; perhaps Evan doesn’t want to make any comments in this thread until whatever may be announced at the Meetup…
1 Like
I’m afraid that I have a bit of a bias against LLVM in general as I’ve been bit a couple of times where their optimization passes turned out to be de-optimization passes in some hard-to-determine-in-advance cases, but I do give them that LLVM optimizes AVX code better than GCC. Actually, this isn’t a decision that one has to make immediately, as with the “platform” approach, alternate back-end code generators can be supported. I could see that this MLIR could be easy to use if a ML keyword can generally just be converted to a MLIR instruction and the rest of the code generation chain taking care of everything else…
I would never suggest writing a custom native code generator for a new language, and I think that was a mistake for Google’s Go language (and as proposed for the V language which aims to be a better Go), among others. However, although not FPat all, C is a basic language that is well known and GCC (and Clang) have had tens of years of evolution to be able to optimize a lot of things and even just slightly optimized FP code. I’d like to try…
F#/Fable can generate Rust code, and the main reason it isn’t as efficient as direct programmer-written Rust is that F# AST doesn’t have the node flags to be able to help in the generation of Rust; I think we can provide the AST that can generate efficient C code, and it might be easier than generating what MLIR needs as most ML languages depend on Garbage Collection, which I don’t want to use for a C backend…
I missed the Zokka announcement post, it looks like a great project! I’m keeping an eye on it for sure.
2 Likes
Yes - its tricky though isn’t it? Some of the issues with Elm are technical “the bugs” and some of the issues are more organisational - the bus factor, the lack of evaluating and merging any pull requests.
What I like about the direction of Zokka, is that it is giving higher priority to the organisational issues, and taking a conservative approach to the technical issues. We need an off-ramp to a compiler infrastructure that is maintained, and where community members can contribute fixes. Then we need to work out all the details of how that is managed, especially where people disagree about things. None of that is easy to achieve, but I do think its the right first step. Otherwise we just end up with something that we cannot easily migrate existing work onto, and we might as well just go and create another roc or gren or whatever. Getting people on board to a project with limited scope and making it as easy as possible for them to use it is the way to go.
Fixing negative integers in case...of would still be backwards compatible - existing Elm code would run on it fine. But it would not be forward compatible, code taking advantage of the bug fix would not be able to run on vanilla Elm. Full compatability will enable an off-ramp, we can break forward compatability later, once the off-ramp has served its purpose.
But since there are these awkward spots in the language itself, many of which seem to cluster around the Int implementation, eventually they need to be dealt with. Better to take the pain early is also a valid idea, and the one pursued by gren. Lets try the other route and see how that works out.
> ./roc repl
The rockin' roc repl
────────────────────────
Enter an expression, or :help, or :q to quit.
» f = \x, y -> x + y
<function> : Num a, Num a -> Num a
» f 2
── TOO FEW ARGS ────────────────────────────────────────────────────────────────
The f function expects 2 arguments, but it got only 1:
6│ f 2
^
Roc does not allow functions to be partially applied. Use a closure to
make partial application explicit.
»
You just reminded me. I think this is why I never bothered with Roc, this isn’t really even what I would consider to be FP. I also searched the docs but cannot find out how to “Use a closure” - any ideas?
If we have
add x y = x + y
partial application is
add2 = add 2
I guess the following is what ROC means with “closure”:
add2 y = add 2 y
1 Like
Or even more generally:
addCurried = \ n -> \ v -> add n v # last function captures `n` as a closure
add7 = \ y -> addCurried 7 y # left association of function application
by which we have defined currying and partial application by using closures.
This is what languages that have currying at the compiler level do automatically; Roc makes us do it manually when we want to emulate currying and partial application.
Lack of currying is said to be so one gets this error when the number of arguments doesn’t match the number of parameters to be less confusing for noobee’s to FP…
The message one would get if the language had currying and unintentionally gave too few arguments would be something like “Type does not match, expected value type such and such, got function signature such and such”, and if too many arguments “something is wrong fallowing function add call; have you provided too many arguments?”…
It’s funny: Roc thinks nothing of providing all kinds of sugar for the strangest things such as backpassing and all the symbolic operators, but doesn’t go the extra step here along with helpful error messages when types don’t match that give hints as to what the problem most likely is for currying/partial application…
But in Elm I can do:
add (x, y) = x + y
and now Elm checks I got the right number of parameters. Just switched around the default behaviour I guess. It all seems a bit arbitrary rather than useful or helpful.
The more common way of doing things in functional programming is for automatic currying. I find this tends to encourage thinking in more functional terms, and concepts such as chaining functions, higher order functions, and patterns and dsls build around partial applications and so on. I can see some of that is a bit off putting to complete beginers to FP, but you are only a beginner for a short while, compared to all the years you work on those skills and appreciate being able to apply them without resistance from the language. Isn’t Elm such a nice language to work in.
I’m not sure of the relevance of the above example, as you’ve removed the currying by enclosing the parameters in a tuple and the number of arguments then must agree with those required by the tuple, but I guess you are saying that if beginners have problems with currying, they have the option in curried/partial application-languages of removing it by using all single parameter functions taking either a tuple (or a record in Elm if there are more than three parameters).
Actually, C-style programmers will like the above form of programming because it looks exactly like the syntax they must use in those languages…
The more common way of doing things in functional programming is for automatic currying. I find this tends to encourage thinking in more functional terms, and concepts such as chaining functions, higher order functions, and patterns and dsls build around partial applications and so on. I can see some of that is a bit off putting to complete beginers to FP, but you are only a beginner for a short while, compared to all the years you work on those skills and appreciate being able to apply them without resistance from the language. Isn’t Elm such a nice language to work in.
I think you are preaching to the choir here, as anyone here has likely long passed the stage where we don’t groc currying…
Hello everyone,
I mentioned the donation campaign to Evan and he politely declined. So we can close this loop for now 
2 Likes