Re: Translation for extension is a bad idea

[cwitty at newtonlabs dot com (Carl R. Witty)]

Brent Fulgham <brent.fulgham@xpsystems.com> 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
compiler.)

Carl Witty
cwitty@newtonlabs.com