This is the mail archive of the
guile@sources.redhat.com
mailing list for the Guile project.
RE: Translation for extension is a bad idea
- To: cwitty at newtonlabs dot com
- Subject: RE: Translation for extension is a bad idea
- From: Brent Fulgham <brent dot fulgham at xpsystems dot com>
- Date: Thu, 13 Jul 2000 17:03:58 -0700
- Cc: guile at sourceware dot cygnus dot com
> > 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?
>
You're right -- I just re-read the documentation. It uses the C
compiler for linking the object code it emits, rather than producing
a C file to compile natively.
> 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.)
>
Right. So it looks like I'm down to Eiffel as the only remaining
example I am aware, and it seems that C (for this discussion) is
not really high-level...
So, perhaps the GNU project should focus on a common interpreter engine
(similar to a JVM) that would support multiple high-level language
front-ends?
-Brent