| Message ID | 20220419232736.272970-1-philip@philipmcgrath.com |
|---|---|
| Headers | show |
| Series | gnu: elm: Update to 0.19.1. Add build system & importer. | expand |
Hi Philip, Philip McGrath <philip@philipmcgrath.com> skribis: > This patch series updates Elm to version 0.9.1, then adds an > 'elm-build-system' and a 'guix import elm' command. Impressive! > To exercise the new features, this patch series then: > > * Build the front-end for the `elm reactor` command (which is written in Elm) > and adds a variant of Elm to Guix with the command enabled; > > * Builds 'elm-todomvc', an official example of a basic Elm application; and > > * Builds a feature-rich third-party package, "terezka/elm-charts": > <https://elm-charts.org>. Woow, neat. Annoying question that I have to ask: do these packages bundle JavaScript libraries? If yes, is it source or is it “minified”? (My take is that we could tolerate some level of bundling if “doing the right thing” is impractical, but it’d rather be source.) Thanks, Ludo’.
I sent a few comments to individual patches that probably warrant a v2, but overall I think the patch series is almost ready to go. Thanks! Ludo’.
Hi, Hi, On 5/1/22 16:22, Ludovic Courtès wrote: > Hi Philip, > > Philip McGrath <philip@philipmcgrath.com> skribis: > >> This patch series updates Elm to version 0.9.1, then adds an >> 'elm-build-system' and a 'guix import elm' command. > > Impressive! > Thanks! >> To exercise the new features, this patch series then: >> >> * Build the front-end for the `elm reactor` command (which is written in Elm) >> and adds a variant of Elm to Guix with the command enabled; >> >> * Builds 'elm-todomvc', an official example of a basic Elm application; and >> >> * Builds a feature-rich third-party package, "terezka/elm-charts": >> <https://elm-charts.org>. > > Woow, neat. > > Annoying question that I have to ask: do these packages bundle > JavaScript libraries? If yes, is it source or is it “minified”? > > (My take is that we could tolerate some level of bundling if “doing the > right thing” is impractical, but it’d rather be source.) > Short answer: no, they don't! Longer answer: 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. [1]: https://guide.elm-lang.org/interop/ [2]: https://github.com/elm/compiler/blob/master/hints/optimize.md -Philip
Hi, On 5/1/22 16:41, Ludovic Courtès wrote: > I sent a few comments to individual patches that probably warrant a v2, > but overall I think the patch series is almost ready to go. > > Thanks! > > Ludo’. Thanks for taking a look! I have a few other things to wrap up before I return to this, but I'll put together a v2 relatively soon. Tangentially, I learned after sending this series about a Rust-based runner [1] for "elm-explorations/test" tests, which may be easier for us to package than the Node.js-based runner.[2] Still, I'd probably save that for some future patch series. -Philip [1]: https://github.com/mpizenberg/elm-test-rs [2]: https://github.com/rtfeldman/node-test-runner
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’.
Hi, This patch series updates Elm to version 0.9.1, then adds an 'elm-build-system' and a 'guix import elm' command. To exercise the new features, this patch series then: * Build the front-end for the `elm reactor` command (which is written in Elm) and adds a variant of Elm to Guix with the command enabled; * Builds 'elm-todomvc', an official example of a basic Elm application; and * Builds a feature-rich third-party package, "terezka/elm-charts": <https://elm-charts.org>. -Philip Philip McGrath (30): gnu: elm-compiler: Update to 0.19.1. gnu: elm: Rename package to match the command. guix: Add elm-build-system and 'guix import elm'. gnu: Add elm-core and elm-json. build-system/elm: Add implicit Elm inputs. gnu: Add elm-virtual-dom. gnu: Add elm-html. gnu: Add elm-svg. gnu: Add elm-time. gnu: Add elm-url. gnu: Add elm-browser. gnu: Add elm-bytes. gnu: Add elm-file. gnu: Add elm-http. gnu: Add elm-parser. gnu: Add elm-project-metadata-utils. gnu: Add elm-explorations-markdown. gnu: elm: Support 'elm reactor'. gnu: Add elm-todomvc. gnu: Add elm-debois-elm-dom. gnu: Add elm-random. gnu: Add elm-explorations-test. gnu: Add elm-danhandrea-elm-date-format. gnu: Add elm-danhandrea-elm-time-extra. gnu: Add elm-justinmimbs-date. gnu: Add elm-justinmimbs-time-extra. gnu: Add elm-myrho-elm-round. gnu: Add elm-ryannhg-date-format. gnu: Add elm-terezka-intervals. gnu: Add elm-terezka-elm-charts. gnu/local.mk | 4 +- gnu/packages/elm.scm | 767 +++++++++++++++++- .../elm-compiler-disable-reactor.patch | 71 -- .../patches/elm-compiler-fix-map-key.patch | 38 - .../elm-offline-package-registry.patch | 71 ++ .../patches/elm-reactor-static-files.patch | 251 ++++++ guix/build-system/elm.scm | 176 ++++ guix/build/elm-build-system.scm | 380 +++++++++ guix/import/elm.scm | 148 ++++ guix/scripts/import.scm | 3 +- guix/scripts/import/elm.scm | 107 +++ 11 files changed, 1883 insertions(+), 133 deletions(-) delete mode 100644 gnu/packages/patches/elm-compiler-disable-reactor.patch delete mode 100644 gnu/packages/patches/elm-compiler-fix-map-key.patch create mode 100644 gnu/packages/patches/elm-offline-package-registry.patch create mode 100644 gnu/packages/patches/elm-reactor-static-files.patch create mode 100644 guix/build-system/elm.scm create mode 100644 guix/build/elm-build-system.scm create mode 100644 guix/import/elm.scm create mode 100644 guix/scripts/import/elm.scm