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


> > 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.
> 
Hmm.  You are correct that it is better to have bug detection/backtrace
occurring in such a way that the error output is meaningful to a 
programmer familiar with the "translated" language, rather than the
behind-the-scenes language (Scheme).  

However, we may be comparing apples to oranges here.  Objective CAML,
for example, can run in an interactive (CAML) mode, but it also
can produce native code, which is produced by the CAML compiler
emitting (translating the CAML to) ANSI C code, which is passed to 
your system's C/C++ compiler.  Eiffel works this way as well.

> 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 unit.
> 
Or at least "stub" glue libraries that perhaps give Scheme hints
that it needs to load its own GTK interface.  I.e., rather than
having the actual Python GTK interface library, for example, you
would have a Scheme mapping of Python->GTK calls to Scheme.  (In
effect, an additional part of the translation).

> >> 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.
> 
Yes.  But this is a concrete issue, not a theoretical one.  There is
(as yet) no firm theoretical basis for saying that a translation
would not be useful.  If you wish to argue from a "concrete" basis,
we could say that GNU should use the Perl language for extension,
since more people know it, it's actively maintained, it has more
available extension libraries, etc., 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).
> 
Aside from the examples of CAML and Eiffel (which produce ANSI C that
is compiled to native binary on the user's system), I cannot.  I 
agree that most recent work seem to be the intermediate
presentation -- and perhaps this is really the best system.  Embed
a single interpreter for the byte-code (be it Java bytecode, 
Perl's bytecode, Python's bytecode, etc.) and provide translation
(compilation) from each language to this intermediate form.

I can't speak to Guile's internals, but I know MzScheme uses an
internal byte-code representation as well.  Equipping Guile with
a similar mechanism might well be the best option, since only
the byte-code engine would need to be understood in much detail to
embed various languages in your program.

So this might be a "Common Language-Backend" solution to the
translation problem...

Regards,

-Brent


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