Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Alternative Bytecodes for OCaml
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Michal Moskal <malekith@p...>
Subject: Re: [Caml-list] Alternative Bytecodes for OCaml
On Wed, Aug 25, 2004 at 07:09:02PM -0500, John Goerzen wrote:
> On Wednesday 25 August 2004 5:10 pm, Yamagata Yoriyuki wrote:
> > The conclusion of the F#, and several SML-to-Java bytecode projects
> > is that JVM and .NET are too restricted to OO paradigm, I remember.
> > See the thread begins
> > http://caml.inria.fr/archives/200102/msg00048.html
> 
> I'm not sure I buy that.  For one, Python already exists for both, and I 
> believe it implements all the stumbling blocks commonly mentioned here 
> save for tail recursion optimization.  Secondly, there are functional 
> languages existing for .NET: Nemerle, SML, Haskell (via both ghc and 
> Hugs), Scheme, Lisp.  I hardly think that one could claim that either 
> VM is too limited to make an implementation.  We even have preliminary 
> OCaml interpreters for Java, and the Nemerle language is *very* similar 
> to OCaml.  The syntax is different, but from what I've seen, the 
> language is similar enough that it should be possible to make a camlp4 
> printer to output in Nemerle.

I guess it would be possible for Caml Light, but not for OCaml. OCaml
has very sophisticated type system with regard to objects and modules.
Neither of these fit with the .NET object oriented model -- it's simply
too restricted. This is one of reasons Nemerle exists.

It's probably possible to implement OCaml's objects using .NET
objects, using one interface per method, or casting everything down
to System.Object, but this doesn't seem a) pretty, b) fast nor c)
interoperable.  And c) is one of the main reasons .NET exists. 
You would at least have to add .NET-like classes and interfaces to OCaml
to make using .NET libraries possible. And if you want to write
libraries in such OCaml.NET, you would be restricted to these types at
the edges. And this in turn means you have to have very good support
for these features, and this turns out not to be so easy -- after one
year of development we still don't have full support for this stuff in
Nemerle.

-- 
: Michal Moskal :: http://www.kernel.pl/~malekith :: GCS !tv h e>+++ b++
: ::: Logic is a nice contrast to the Real World. :: UL++++$ C++ E--- a?

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners