This is the mail archive of the 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: Translation for extension is a bad idea

11-Jul-00 15:18 you wrote:
>> 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.

I'm not sure. You want bug detection in terms of ORIGINAL language.
GNU Pascal DOES NOT convert code to C but to SPECIALLY DESIGNED internal
language where such reporting is easy. The same thing happened with
Cfront: novadays it's not used but instead C++ and C have common backend.

Conclusion: common target structure to compile language into works Ok
while conversion to language NOT SPECIALLY designed to be target of
conversion (and thus with embedded facilities to track things back to
source level) works bad.

Perhaps scheme can be extended somewhat to make it suitable as backend
language but "as it is" it works bad.

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

Not exactly. Even if GNU Pascal, GNU C++, GNU Ada and so on share common
backend with GNU C you STILL need glue libraries like GTK-- or CRT pascal

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

What's currently available is just plain unusable :-( It works as "proof of
concept" and even for that it does not work very well.

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

Can you show any sample where this approach is used for LONG period of time
and not to make something "here and now" ? I'm seeing shift to native languages
instead and some non-human-readable intermediate presentation (GNU Compiler
Collection, Java-bytecode based languages, etc).

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]