This is the mail archive of the
mailing list for the Guile project.
Re: Translation for extension is a bad idea
- To: Brent Fulgham <brent dot fulgham at xpsystems dot com>
- Subject: Re: Translation for extension is a bad idea
- From: cwitty at newtonlabs dot com (Carl R. Witty)
- Date: 12 Jul 2000 13:24:49 -0700
- Cc: Khimenko Victor <guile at khim dot sch57 dot msk dot ru>, guile at sourceware dot cygnus dot com
- References: <EDFD2A95EE7DD31187350090279C6767B50711@THRESHER>
Brent Fulgham <firstname.lastname@example.org> writes:
> 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.
As far as I can tell, OCaml can either compile to bytecode or to
assembly language...I don't think there's a backend that compiles to
C. Perhaps you're thinking of the GHC Haskell system?
> > 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...
There are several systems which compile to C as a "portable assembly
language", but they use C as a very low-level language (for instance,
the cases I'm aware of subvert all of C's typechecking). There's
actually a promising effort underway to create a new "portable
assembly language" language, C--.
However, I don't recall any instances of systems which compile one
high-level language into another (unrelated) high-level language. (I
believe there used to be a Yale Haskell system that compiled Haskell
into Common Lisp, but it's been unmaintained for years.) (I say
"unrelated" to exclude examples like Screamer, which compiles the
language of "non-deterministic Common Lisp" into Common Lisp; and the
Series package for Common Lisp, which arguably could be called a