Re: Translators again

[Jost Boekemeier <jostobfe at linux dot zrz dot TU-Berlin dot DE>]

Ian Bicking <bickiia@earlham.edu> writes:

>   (eval-language 'tcl "set x 10")
> 
> But I assume you have another idea of how you'd do this too.

I don't like a "centralized" approach.  I think that a foreign language
translator should be a module which implements everything
needed to parse, evaluate and print expressions in this foreign
language.  For example you contribute a (lang tcl repl) module and
throw it into the directory lang/tcl which you own.

On the other side there are people who want to contribute modules
written in a foreign language for which a translator exists.
These people have to provide 
a) the foreign language file (of course) and 
b) an interface module which describes the services that the
foreign language file offers and does everything necessary to 
parse the actions written in the foreign language.

They do this by creating an interface module which a) opens your
lang/tcl module and use the services it provides and b) use these
services to parse the foreign language actions.  We have three roles:
a customer using a foreign language module must open the interface
module implemented by a service contributor (service written in a
foreign language) and we have person who has written and maintains the
foreign language translator.

That means that you cannot associate a foreign language file with more
than one language.  I think that ctax is special because it is a
superset of scheme. It simply passes scheme expressions on to the
scheme evaluator.


> Do you mean to do:
> 
> guile> (open (ice-9 tcl))
> tcl> set x 10

Yep.  Or something like that I think.

The module system provides the commands

(go <module>)        :start a new repl in module by calling 
                      an exported feature named "repl"

(modul-open <module>):make exported features visible to the 
                      current module
and others ...


It has a programmatic and a declarative interface:

programmatic                   |  declarative
---------------------------------------------------------
(define-module (my))           |  (module (my)
(module-open (ice-9 guile))    |    (open (ice-9 guile))
(module-export a b c)          |    (export a b c))
(module-close (ice-9 guile))   |   n.a.
(go ...)                       |   n.a.


The declarative interface is internally re-written into
the more primitive (module-xxx) clauses so that you
can ignore the (module ...) syntax completely.

;; start a scheme repl in (ice-9 tcl) [see note 1]
user/guile> (go (ice-9 tcl))
ice-9/tcl> (export call-with-current-continuation)
ice-9/tcl> (define call-with-current-continuation 'in-tcl)
ice-9/tcl> <control-d> ;; terminate (ice-9 tcl)'s repl

;; start a scheme repl in guile
user/config> (go (user guile)) ;; the module module
user/guile> (module-open (ice-9 tcl))
user/guile> call-with-current-continuation -> 'in-tcl

;; now visit the module (willie tcl-test)
;; which opens (ice-9 tcl) and exports the repl that 
;; tcl provides.  
user/guile> (go (willie tcl-test))
user/willie> (+ 1 2) -> error
user/willie> 1 + 2 -> 3 

Note 1: Because (ice-9 tcl) exports a feature called repl, the module
system "(go ...)" will try to start this repl.  The problem is that in
this special case we want a scheme repl and not the repl that this
module provides.  This is a bug.  One solution would be to require
that only packages ("compount modules") may have repls.


> > You'll have to emulate dynamic scoping (with fluids?) as environments
> > can't help you further.
> 
> I was never clear on what environments actually allowed, but I had
> hoped that dynamic scoping would be part of it :-(  What's going to
> be done for elisp?

I think that Per Bothner uses fluids to emulate elisp.


Jost