use-modules in gexps

use-modules in gexps

[Ricardo Wurmus]

Hi Guix,

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.

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.

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?

--
Ricardo

Re: use-modules in gexps

[Ludovic Courtès]

Hello!

Ricardo Wurmus <rekado@elephly.net> 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’.

Re: use-modules in gexps

[Ricardo Wurmus]

Ludovic Courtès <ludo@gnu.org> writes:

>> 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?

When I wrote “state” I had the list of modules encountered in mind, so
that it would be possible to collect all marked instances of
“use-module” and hoist them to the top, in effect doing automatically
what is achieved manually by using “with-imported-modules” with a list
of modules.

--
Ricardo

Re: use-modules in gexps

[Ludovic Courtès]

Hi,

Ricardo Wurmus <rekado@elephly.net> skribis:

> When I wrote “state” I had the list of modules encountered in mind, so
> that it would be possible to collect all marked instances of
> “use-module” and hoist them to the top, in effect doing automatically
> what is achieved manually by using “with-imported-modules” with a list
> of modules.

I see.  I guess this would be possible only by adding restrictions on
what can go into a gexp: the position of ‘use-modules’ or
‘define-module’ forms in a gexp, the options they are passed, etc.

Ludo’.