This is the mail archive of the
guile@sources.redhat.com
mailing list for the Guile project.
Parametric modules
- To: Mikael Djurfeldt <djurfeldt at nada dot kth dot se>
- Subject: Parametric modules
- From: Jost Boekemeier <jostobfe at linux dot zrz dot TU-Berlin dot DE>
- Date: 14 Aug 2000 19:31:59 +0200
- Cc: guile at sourceware dot cygnus dot com
- References: <E13NUr0-000412-00@linnaeus.mit.edu>
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) :>