Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

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: 2004-08-25 (16:26)
From: Jason Smith <jns28@s...>
Subject: Re: [Caml-list] Alternative Bytecodes for OCaml

> And that is, in my mind, the key benefit.  I am just learning
> about .NET, so let's talk about Java first.

*snip cool python stuff*

> And you're right, with .NET this benefit grows even more.  I can access
> not just Java stuff there, but also C#, some C++, Python, Perl,
> whatever else.  It's a lot to draw on, and no glue.

Yes, I have little experience with python but I've written a functional
language compiler for .NET for the language Mondrian[1]. Expect a new
release soon, as soon I as I finish it with hopefully non-structural
subtyping and recursive types (website is a little behind the times).

In Mondrian I can bind to C# simply by doing:

invoke System.Random.Next(Integer) <obj instance>

At the moment you have to supply the parameter type because the original
implementation couldn't resolve overloadings, Integer is the return type.
Currying affords a form of dynamic binding here as I can delay supplying the
<obj instance> untill later in this case because Next does not expect a
argument the objc instance is the next argument bound. invoke uses the
reflection libraries to check if the object instance bound later is really
carrying a member with System.Random.Next defined on it. Obviously
realistically the only object carrying this method is going to be a instance
of System.Random but the idiom is easily extendable. If we are interested in
making sure we do not get any dynamic exceptions then we can constrain the
type variable bound to invoke with the constraint a <: { System.Random.Next
(Integer) }, so that we can check it statically.

Some immediate benefits over the JVM are an official release with support
for Generics, parameteric polymorphism is now directly expressible in byte
code and now *finally* we have contra/covariant delegate types which allows
me to express proper subtype semantics over function types (where functions
are passed using delegates, a natural homomorphism).

Incidentally the above syntax has been adopted by Hugs98.NET [2], mostly
because the original guy who worked on Mondrian, Eric Meijor, is development
lead for Hugs98.

Cheers, J.


To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: