Re: Parametric modules

[Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>]

Jost Boekemeier <jostobfe@calvados.zrz.TU-Berlin.DE> writes:

> I think what we really need in this case is support from the module
> system.  Namely "parametric modules" which are similar to ML's
> functors.  I think the problem with your proposal is that inter-module
> connections are implicit, not explicit.

I'm not sure which inter-module connections you are talking about.

In my proposal there is no connection between the translator module
and the run-time environment it provides.

However, it does setup a connection between the run-time environment
and modules written in the language.

Is it this connection you are referring to?

I agree that this might not be entirely beautiful.  Could you explain
further why this is a problem?

But what I think maybe is even less beautiful is the way the
translator module connects to Guile.  Guile itself will be forced to
do magical things with the module system in order to use the language
modules.

It is interesting that you mention parametric modules.

I can imagine they could have some use in this situation, but I
believe your suggested use is wrong, because the translator module
seems to mix bindings from the run-time environment with bindings used
by the Guile system to parse and translate the language.  Or have I
misunderstood your suggested use of the translator module?

> How do you like the following changes:
> 
> 
> [...]
> 
> A translator is a parametric module, implemented in Scheme, C or a
> mixture of both.  [...]
> 
> * How to tell Guile to read code in a different language (than Scheme)
> 
> There are two methods of specifying which translator to use when
> reading a file:
> 
> ** Command option
> 
> -m    --module-command <module language expression>
> 
> Example:
> 
> guile --module-command "(use-parametric-module ((ice-9 tcl->scheme) :parameter (my tcl test1) :option ... ))"
> 
> will use the tcl->scheme translator, bind "my/tcl/test1.tcl" into its
> adress space (see below) and create a fresh instance of the
> combination of tcl->scheme + my/tcl/test1.tcl

I think this is too complex to be useful for everyday life.

> ** Commentary in file  dropped

OK

> ** File extension  dropped

Why?

> The section "** Remove scm:eval-transformer ...": I've lost you here.
> 
> Will `eval' "call" the `transformer' directly?  If so, what's the
> gain?  And what are the environment smob's good for?

Yes.  That section of the proposal is not completed, so you're fully
entitled to get confused.

From the proposal:

  Note that this level of transformation is something independent of
  language translation.  *This* is a hook for adding Scheme macro
  packages and belong to the core language.

This is the step after language translation.  Some modules might want
to use some particular new fancy macro package.  This is a hook for
that.

This hooks already exists.

I just propose that we simplify things by removing the global binding
scm:eval-transformer.