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]

Re: Language translation proposal 1.4


Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:

>   ctax> x = read ();
>   1+2;
>   1+2;
>   ctax> x

What happens in this case:

euler> ,x = read();
euler> ,in = ,x + "2"

That's why I tried to avoid escape sequences.  Although that isn't a
bad idea in general, for example VI uses this technique too.

But you're right that ^D is problematic, what about 
^X^F <module-command> to switch from one to another module?


> The module header of the current module system is the form
> 
>   (define-module NAME OPTION1 ...)
> 
> You can specify a translator using the option
> 
>   :language LANGNAME
> 
> where LANGNAME is the long or short form of language name as described
> above.
> 
> The translator is being fed characters from the module file, starting
> immediately after the end-parenthesis of the module header form.
> 
> NOTE: There can be only one module header per file.
> 
> It is also possible to put the module header in a separate file and
> use the option
> 
>   :file FILENAME
> 
> to point out a file containing the actual code.
> 
> Example:
> 
> foo.gm:
> ----------------------------------------------------------------------
> (define-module (foo)
>   :language emacs-lisp
>   :file "foo.el"
>   :export (foo bar)
>   )
> ----------------------------------------------------------------------
> 
> foo.el:
> ----------------------------------------------------------------------
> (defun foo ()
>   ...)
> 
> (defun bar ()
>   ...)
> ----------------------------------------------------------------------


What happens in this case:

(define-module (client) :language emacs-lisp :file "foo.el" :export (baz))
(define baz 1)

Which symbols from foo are visible in client?


And what happens in this case:

(define-module (client) :use-module (foo))

Which symbols are visible in client? 

How could client specify the translator to use.  For example if client
don't want to use "emacs-lisp" but a different translator to translate
foo?


It seems to me that the foo module above is directly coupled with the
emacs-lisp translator.  Although it is possible to modify the
search-path so that the module machinery can find the translator that
client wants, modifying the load-path affects all other modules,
because it is a global variable located in (config).

A simple fix would be to define a separate load-path per module.  But
in general I think changing the translator into a parametric module is
better. -- The fact that bindings exported from the translator module
and bindings exported from foo are visible (seem to be "mixed")
through the intermediate language environment is an artefact of the
current module system.  In general the interface that clients of a
parametric module see is the union of the interface of the parametric
module + the interface of the parameter module: Ip + I.


Jost


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