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
about OcamIL
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2010-05-16 (03:19)
From: Goswin von Brederlow <goswin-v-b@w...>
Subject: Re: [Caml-list] about OcamIL
Jon Harrop <> writes:

> Goswin wrote:
>> Hardly any business today has an inhomogene environment. And if the
>> environment is homogene then the vm gives you 0 advantage. It just
>> costs you overhead to emulate.
> A Common Language Runtime (CLR) is an obvious counter example => the shared
> VM gives you safe and high-level interoperability between languages. For
> example, you can pass garbage collected data structures between languages by
> reference because they share a single GC. Without a CLR, you generally
> resort to painstakingly copying everything for no reason and give up for
> anything non-trivial (like closures) and often end up with segmentation
> faults and no working code.

And there we disagree. A VM does not give you savety or high-level
anything in general. A VM can be as unsafe and low-level as you
like. Most VMs won't stop you when you write an int to some (allocated)
memory address and load a float from the same address. And BANG you have
total garbage. Most VMs won't catch array/string over/underruns. And so
on. The safety usualy comes from the high-level language used on top of
the VM.

As for interoperability you get the same if you define your CLR to be
native mode with ONE specific GC. You still need to port every single
languag you use to that CLR, native or VM.

> I was once asked how someone might interoperate between Standard ML and
> OCaml (two very closely related languages) and my answer was XMLRPC.
> Contrast that with F# development where almost every program in existence
> relies entirely upon seamless two-way interoperability with C# libraries
> like WPF.

And how do I get the F# code to use my haskell lib?

The interoperability comes from F# and C# having common grounds. Not
from them running in a VM. The common language runtime is the key there.

> Cheers,
> Jon.


PS: There is a java CPU so java bytecode can run native. I wonder when
someone will build a F# cpu.