[bug#55030] [PATCH 00/30] gnu: elm: Update to 0.19.1. Add build system & importer.

[Ludovic Courtès]

Hi Philip,

Philip McGrath <philip@philipmcgrath.com> skribis:

> Elm basically takes the view that the existing JavaScript/NPM thicket
> should be considered harmful. It imposes a lot of very strict 
> requirements on Elm "packages" (vs. "applications") to avoid whole
> classes of problems. Not all of them are precisely the requirements I 
> would have chosen, but I like them better than the alternative chaos.
>
> (One reason I gave this a try was to get some hands-on experience
> writing a build system and importer in a simplified context before 
> trying to write `racket-build-system`.)
>
> In particular, allowing arbitrary JavaScript would defeat the strong
> guarantees Elm wants to offer as a statically-typed, purely-functional 
> language with compiler-enforced semantic versioning (well, for a
> decidable subset of "semantics") that can make runtime errors 
> vanishingly rare in practice. To that end, Elm requires that
> "packages"---the things `elm-build-system` knows how to build---be 
> written in pure Elm, with no JavaScript at all. For "applications",
> interop is limited to asynchronous message passing.[1] The only two 
> "applications" in this series, the `elm reactor` frontend and
> `elm-todomvc`, don't use any message passing.
>
> Of course, Elm needs some way to implement primitives. These are
> provided by modules in the `Elm.Kernel.*` namespace, which are written 
> in JavaScript with the undocumented, unsafe conventions expected by
> the Elm compiler. The Elm compiler only allows kernel modules in
> packages in the `elm/*` and `elm-explorations/*` namespaces, so users
> can know that third-party packages won't break Elm's guaranteed, and
> the compiler is free to change its internal APIs without breaking
> anything. (This is free software, so you could patch the compiler to
> do whatever you want: it's just a community norm so strong it's
> expressed in code.) Even this is all source code with whitespace and
> comments: it's written in a very stylized way, as an ASM file in
> another compiler implementation might be, but it isn't generated code.
>
> For people who want to "minify", Elm suggests flags for UglifyJS that
> can also do otherwise-unsafe whole-program optimization of the
> compiled "application".[2] (Compiling "packages" emits only an
> internal representation, not JavaScript.) In my own projects, I've
> also done other post-processing, like adding LibreJS comments and
> converting the output to an ES6 module. I haven't tried to make
> `elm-build-system` do any of those kinds of things for "applications":
> I think we should find more examples of Elm applications people would
> want to package for Guix first, rather than trying to guess what they
> might need.

Thanks for explaining!  Elm is fascinating in many ways.

Ludo’.