Re: use-modules in gexps

[Ludovic Courtès]

Hello!

Ricardo Wurmus <address@hidden> skribis:

> I just watched the excellent FOSDEM talk about G-expressions by Chris
> Marusich.  One person asked at the end about why it is necessary to use
> “with-imported-modules” when inside of the G-expression “use-modules” is
> used.

Chris and I discussed it (I think the paper mentions it).  There are
several reasons:

  1. Scope and importing are two different things.  The user needs fine
     grain control over what’s imported and what’s not (for example, you
     generally don’t want to import Guile-provided modules; sometimes
     you want to important a module’s closure, sometimes not, because
     you know some of the modules are provided by some other means.)

  2. ‘use-modules’ and ‘define-module’ are meant to be top-level forms,
     but a gexp can be non-top-level, and thus they do not have a
     ‘use-modules’ form.

     For example, the ‘start’ and ‘stop’ fields of <shepherd-service>
     are non-top-level, which is why there’s an additional ‘modules’
     field there.  All the ‘modules’ field are appended to form a
     ‘use-modules’ form in the resulting shepherd config file.

  3. Guile has several ways to bring modules in scope: ‘use-modules’,
     ‘define-module’, and both of these support #:select, #:prefix,
     etc.  These features should remain available.

So I took the conservative approach of not trying to merge these two
related but different features.  The downside is that it looks
redundant, but the upside is that there’s no loss of expressivity.

> I wondered if perhaps we could add a G-expression compiler for module
> imports, so that instead of
>
> (with-imported-modules (source-module-closure '((my module)))
>   #~(begin
>      (use-modules (my module))
>      …))
>
> we would do
>
>   #~(begin
>      #$(use-modules (my module))
>      …)
>
> which would have the effect of adding (my module) — or the module
> closure – to the list of modules needed by the current G-expression.

I think the syntax should be different because #$/ungexp has a different
meaning.  However, that would leave open the question of how to select
the subset of the module’s closure you want to import, etc.

> Can a G-expression compiler help accumulate state (e.g. by making
> G-expressions values in the state monad) or can it only be compiled down
> to a value at the current location?

The latter.  What state would you want to accumulate?

Really happy to see the positive effects of Chris’ talk!  :-)

Ludo’.