RE: Translation for extension is a bad idea

[Brent Fulgham <brent dot fulgham at xpsystems dot com>]

> if I want to use a standard language, I embed the an
> interpreter for that standard language.
> 
> I don't go around designing my own langauge, because (quoting the
> GUILE webpage)
> 
>       A good [..] language takes time. We've taken that time
>       for you.
> 
> I would defeat the purpose of having a full-blown interpreter for a
> mature language by designing my own.
>

Well, you are not designing your own language.  You are providing
a translation from one language to another.  This is already common
practice in GNU Pascal -> C, or GNU Eiffel -> C, etc.  Scheme is
quite adept at these kinds of jobs.

In addition, you move the work of continually updating multiple
interpreter engines in your application to tracking a single
interpreter (Guile).

Finally, it is unlikely that you would be responsible both for your
application and the [foo] -> Scheme translator.  For example, an
implementation of Python exists in Java (JPython).  This allows 
Python to be run in Java-enabled applications (such as web servers).
We are dealing with a similar concept here.  (Note:  I realize that
JPython is an implementation of Python in Java, rather than a
translation of Python code to Java, but such animals exist).  See
also Kawa, which does translate (compile) Scheme source code into
Java bytecode.
 
> 
> Brent Fulgham:
> 
> >This is especially true where you have multiple users who each prefer
> >a different language for extension.  Linking to 'n' different
> >interpreter binaries, using 'n' different embed-API's and 'n'
> >different sets of interpreter quirks rapidly produces a massive
> >problem space for the application developer, and for debugging
> >problems with a user's scripts.
> 
> Again, I don't buy this. If I were to use GUILE, I'd have to use n
> different translators each with their own quirks. As a bonus, there
> are much less developers working on GUILE translators than on each of
> the Tcl/Python/Perl languages, which would result in less rapid
> bugfixes.
> 

True -- this is a good point.  However, it is not unlikely that good
translators will exist that will track their target languages better
than what is currently available.

> And I don't really believe that a developer will give thought to a "we
> want Tcl for extension" when there is already a functioning Scheme
> extension mechanism, especially if he/she is short on time. (Well, in
> any case, I wouldn't).
> 
On the contrary -- I did just that for the AOLserver web server (see
http://pywx.idyll.org).  PyWX is a Python extension to AOLserver that
allows much of the system scripting and extension to be done in Python.
This was done in the face of objection from AOLserver users who were
perfectly happy with Tcl.  However, the growing base of Python users
indicates that this was a helpful project.  Plus, a team of great coders
have expanded PyWX far beyond my initial work -- it's becoming a much
more useful extension mechanism than Tcl, IMHO.

> [On the factual side: the only multi-language app that I know of,
> Gnumeric, has different plugins for each language and uses the
> standard interpreters for each.  The developers are actively pursuing
> interoperability using CORBA/Bonobo, and they are not using a unified
> language.
> 
> Perhaps the developers of gnumeric can give us a piece of their mind.]

Or perhaps the Apache team?  I can think of several extension mechanisms
for Apache (Perl, C, Python, etc.)

At any rate, I am not sure that your position (using native interpreters
versus translators) is without merit.  Certainly your arguments are
true.  But I wanted to point out that there are cases (and reasons) 
where a translator makes sense.

Regards,

-Brent