This is the mail archive of the guile@cygnus.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: difficulty of writing translators


Maciej Stachowiak <mstachow@mit.edu> writes:

> * #f is distinct from '() in Scheme, but other lisps have only nil to
> serve the role of both. [...]

> * Scheme has only one namespace, whereas elisp and Common Lisp have
> separate namespaces for variables and functions (and in the case of
> Common Lisp a bunch more too, sigh). [...]

Both these issues were discussed to death a while ago.  I thought
feasible technical solutions had been found?

> > tcl (without tk), 
> 
> Tcl sucks because the only Tcl datatype is a string. Language
> primitives will automatically treat strings as numbers, lists,
> booleans, or code to be evaluated as appropriate. 

Kind of.  Now that Tcl has a byte compiler, things get more
interesting.  Tcl objects have a string representation, but may also
have other representations: if you ask for a list as a string, then
you'll get it (and conversion from list form may happen).  Although
there is a real list type now, for example, it's almost certain that
the semantics just aren't going to translate well.

A better approach, IMHO, is what Rush did: take Tcl, and clean it up,
adding extra (clean) features where you've had to remove features from
Tcl.  That means that many Tcl/Tk programs will Just Work, and most
will require only minor changes, and new users will find the resulting
language much more convenient than they would have found Tcl.

Tk is necessary, if you wish to win over Tcl programmers: most of the
Tcl-only programs also use Tk.  (The remainder require various C
extensions to Tcl; it would obviously be valuable to support Tcl's
FFI, but whether that's feasible or not, I don't know.)

Whatever happened to Rush, anyway?  I don't think it was ever
released, but I don't know why.