Re: difficulty of writing translators

[Maciej Stachowiak <mstachow@mit.edu>]

klaus.schilling@home.ivm.de writes:
> 
> 
> It is often mentioned that translators from other language into scheme are an 
> important point in Stallman's plans for the guile project. Already the tcl-war
> archive logs some arguing about that.
> 
>  Though scheme seems to have everything necessary to adapt elegantly to foreign
> syntaxes, writing particular translators seems always a non-trivial task.
> Are there intuitive estimates, which languages are hard to translate and thus
> require a brainstorming of programmers with decades of experience, and which
> are fairly easy? 
> 

I don't think anything will require decades of experience, but some
might require decades of work :-) In all seriousness, most of the
issues involved just require some cleverness and a bunch of brute
force to preserve the semantics of the original language, while at the
same time offering easy access to code in Scheme or in any of the
other languages (and providing code in themselves to Scheme).


>elisp, gcl, clisp,

I used to think other lisps would be almost trivial, now I am not so
sure. There are two issues I have not been able to figure out.

* #f is distinct from '() in Scheme, but other lisps have only nil to
serve the role of both. Obviously, when Scheme is passing something to
Lisp, you can just convert either of #f or '() to some canonical
representation. But when Lisp passes data to Scheme, it is totally
nonobvious which of the two nil should turn into, even in
context. However, I hear there is deep wizardry afoot to solve this
problem.

* 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). Scheme procedures could be
exported as both function and variable bindings in theory, but in
Scheme a variable can happily contain a procedure at one time and some
other value at another. Hacking set! to check if the value's a
procedure seems cheesy. Going the other way, if some Scheme code
references something that has both function and variable bindings,
what happens? I mean, you could use an explicit selector, but that
looks pretty ugly.

> perl, 

Perl has fairly nice semantics but a hideous syntax. I can only
imagine parsing perl by using the exiting perl parser. Reimplementing
that code in a bogosity-compatible, er, I mean feature-compatible way
would be pretty hard.


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

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

There are also "arrays" (actually hashes), but they are not a proper
datatype, as they are asociated with variables, not with values, so
you can only pass them around by name.

Obviously this is hard to integrate transparently with a language that
has data types.

However, the syntax is exceedingly simple.

> C, C++,  Pascal, Modula, Java, 

All of these are more or less traditional compiled languages. Maybe
supporting a similar syntax is useful, but I don't think supporting
the entire language is.


> to translatability into guile? Or some pseudo-languages like 

> sendmail, TeX, 

These would probably take a lot of work to little gain.

> html,

HTML would be utterly pointless, IMO, it's meant to be a markup
langauge not a programming language.

> VB,

I saw an article once that explained to "advanced Visual Basic
programmers" how to directly access and manipulate arbitrary pointers
from the Basic level. This does not bode well.

> fvwmrc, 

This is obviously a personal interest, since I started a project to
replace the fvwmrc language with guile, resulting in scwm (with other
improvements of course). The fvwmrc language is so underpowered that
translating it is mostly a matter of providing the standard library
and doing a quick hack to read the syntax. However, the other scwm
developers and I are thinking of writing a one-time translator that
would pass over the whole fvwmrc and output a scwmrc instead of a
proper guile translator, because you can't really program in the fvwm
language, so supporting it is only a legacy feature to help people
migrate. It lacks, among other things, such things as control flow,
conditionals, loops, variables, and arithmetic, so it can never be an
extension language.

 - Maciej