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


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

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