Re: difficulty of writing translators

[Jim Blandy <jimb@red-bean.com>]

Maciej Stachowiak <mstachow@mit.edu> writes:

> However, I hear there is deep wizardry afoot to solve this
> problem [of reconciling () and #f].

Yeah... there's no perfect way to solve the problem, but there are
decent ways.  I get the feeling it'll play out the same way the
problem Perl has with "", "0" and "0.0" does.


> * 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).

Elisp has a pretty explicit concept of a symbol object and its slots.
I think the Scheme binding space should be completely distinct, with
magic happening when you import an Elisp module into Scheme.  (Or,
since Elisp has no modules, maybe I should say "the Elisp module".)


> > perl, 
> 
> Perl has fairly nice semantics but a hideous syntax. I can only
> imagine parsing perl by using the exiting perl parser.

Yep.


> > python, 
> 
> Python has, AFAIK, a straightforward syntax and very clean semantics
> from a Schemish point of view. One thing I've heard that may be tricky
> is that lambda in Python does not create proper closures; OTOH I hope
> no one depends on this behavior.

We have to implement the guest languages' semantics *exactly*.  We'll
just have a different kind of procedure object for Python.


> > 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. 

Yep.  Keep in mind that we only have to make the boundary between
Scheme and Tcl convenient, not perfect.  There will be much oddity
here.


Nobody mentioned my favorite pseudo-language: make.  I would love to
replace that incomprehensible garbage with something that made sense.
automake is invaluable, but really a bandaid, not a solution.