Re: Switching to ECMAscript

[Alex Sassmannshausen]

Hi Ludo,

I think this sounds like a great plan! I think a year's re-writing of
package definitions is definitely a price worth paying so we can get rid
of the "ivory tower" functional paradigm: just think of all the other
developers we could recruit to Guix!

I might not be able to help though as my JS is pretty rusty…

Alex

Ludovic Courtès writes:

> Hello,
>
> Over the last few months I have been questioning some of the choices
> that were initially made for Guix.  So I finally took the time to
> investigate more what could be done about it, and specifically I’ve been
> playing with Guile’s ECMAscript front-end.
>
> This is what’s already possible with Guile 2.0:
>
> --8<---------------cut here---------------start------------->8---
> scheme@(guile-user)> ,L ecmascript
> Happy hacking with ECMAScript!  To switch back, type `,L scheme'.
> ecmascript@(guile-user)> require('guix');
> ;;; <unknown-location>: warning: possibly unbound variable `require'
> $1 = #<<js-module-object> 1e325a0>
> ecmascript@(guile-user)> require('gnu.packages.vim');
> $2 = #<<js-module-object> 1660370>
> ecmascript@(guile-user)> $2['vim'];
> $3 = #<package vim-7.4 gnu/packages/vim.scm:32 3ad0c60>
> ecmascript@(guile-user)> $1['open-connection'] ();
> $4 = #<build-daemon 256.14 24fe840>
> ecmascript@(guile-user)> $1['package-derivation']($4, $3);
> $5 = #<derivation /gnu/store/kksx3yywbmkjswwj84d58brrdryvjbwi-vim-7.4.drv => 
> /gnu/store/3wacq9b5qhnk1vn82jggnc10rb1ib4hl-vim-7.4 2d25cd0>
> --8<---------------cut here---------------end--------------->8---
>
> Pretty cool, no?
>
> ECMAscript lacks some features that we’re used to, such as records and
> macros (which we rely on a lot for package definitions, see [0]), but
> OTOH it has the neat notion of “object properties.”  And of course, it’s
> very popular, and GNU hackers are usually familiar with it.
>
> In fact, as I already mentioned in my FOSDEM talk [1], things like npm
> already nicely leverage that, so we don’t even have to come up with a
> new format for package definitions.
>
> So the plan would be to start rewriting package definitions in JS, to
> start with, and then go ahead with the (guix ...)  modules.  Hopefully
> we can reach feature parity with the current Guix within a year or so.
>
> Another thing I would like to improve in the next months is the
> packaging model.  The functional paradigm has its pros, but it has also
> been causing us difficulties.  I would like to allow build processes to
> access the root file system, so we can do things like “post-install
> hooks.”  I don’t have any clear road map on this one though, so
> suggestions are welcome!
>
> Comments?
>
> Thanks,
> Ludo’.
>
> [0] Section 3.3, http://arxiv.org/abs/1305.4584
> [1] See around slide 29,
>     http://www.gnu.org/software/guix/guix-fosdem-20140201.pdf