This is the mail archive of the guile@sources.redhat.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Parametric modules




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.  In short, a parametric module
is a module which can be "invoked" passing several arguments to it
M[P1, ... Pn].  This makes the explicit language-environment, the
language alist and others obsolete and solves the problem with the
read-state and ... [1].

Of course, one can add the association 
(file-extension . language-translater) later by using a 
MIME database [or something].


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


[...]

** Commentary in file  dropped

** File extension  dropped

** Module header

The module header of the current module system is the form
(define-module NAME OPTION1 ...)

You can import a foreign language module by specifying the translator
T together with the foreign language file F to be interpreted by the
translator

:use-parametric-module ( (TRANSLATOR-MODULE1 :parameter FOREIGN-LANGUAGUE-FILE :option read-statexxx ...) ...)

Every parametric module contains a function `main' which will be
called by the module system machinery.  This function accepts the file
name of a foreign language file to be intepreted and optional
arguments (read state etc.)  

A translator module is a parametric module.

Everytime the main' function of a translator module is called it
creates a fresh language-environment (a module) where expressions in
T's language are evaluated by default.  Clients which import from T[F]
actually import bindings from this language-environment.


It is required to export the following procedures:

<translator>-read PORT --> EXPRESSION

[...]

<translator>-translate EXPRESSION --> SCHEME EXPRESSION

[...]


* Proposed Changes to the module system machinery

** Add the option :use-parametric-module to the `define-module' macro

** Add a macro use-parametric-module which calls T's `main' function
   with the given parameters




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?


Jost

[1] ... a nice side effect is, that this solution is compatible with
GODOT. (TM) :>

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]