Re: [Caml-list] interest in a much simpler, but modern, Caml?

[ivan chollet <ivan.chollet@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4082 bytes --]

+ HLVM, Moscow ML, MLTon, etc.
Not too bad in my opinion.

I checked your HLVM and it looks like a really nice project. I had heard
about it before but to be honest it's hard to find information about its
design. Maybe you should release the design documents publicly. It could be
also an good incentive for people to subscribe to your journal.
I looked at the source and I have to say i like it for its simplicity. What
I dislike is that your bytecode runs on LLVM, which is a general purpose
virtual machine, and because it's general purpose, the bytecode and thus the
JIT is a lot more complicated than if the whole infrastructure  was for ML
and ML only. My personal opinion is that the idiosyncrasies of ML deserve
more elegant than this complicated piece of code.
And what i dislike is to debug big pieces of code like this myself
(especially when there is no documentation like with OCaml).

So after reading a few things about HLVM, what I have in mind is basically
the same thing as you did, with only a few minor differences :
- the project should have it's own runtime (with runtime i mean interpreter
+ garbage collector only)
- no need for a JIT at the beginning
- less emphasis on performance at the beginning
- less emphasis on features (your project looks very ambitious in terms of
supported features)
- more emphasis on code safety (than ocaml at least, i don't like to see
segmentation faults). LLVM is not that strong on debugging and code safety
than some other VMs are. (that's just what i've heard and I might be plain
wrong here, but i'm unable to check it myself because LLVM source code is
too complicated for me)
- more emphasis on simplicity and interfaces loosely coupling
- a LOT more emphasis on being community friendly and providing design
documents (for free...)


Now I have to say that LLVM is an amazing project (so is HLVM), and if you
need to have an ML implementation up quickly with good performance and lots
of features supported, then I would admit that this is the only way to go at
the moment. There is no way the community around ML in general and OCaml
specifically would ever come up in the next 10 years with such a
feature-rich runtime and compiler infrastructure.
But now that VMs are becoming a commodity and there is a lot of literature
and resources on the topic, it is also not very time consuming to pull
something from the ground up.
I would be interested to hear your opinion on this.


On Wed, Aug 11, 2010 at 11:19 PM, Jon Harrop <
jonathandeanharrop@googlemail.com> wrote:

> Ivan wrote:
> > I have noted that there are now many implementation of OCaml. Namely :
> > - caml light
> > - jocaml
> > - mincaml
> > - your implementation ?
> > etc.
> >
> > which means there is a lot of interest in implementing tools and runtimes
> for ML.
>
> I'm not sure 3.5 implementations over 25 years is a "lot" of interest but
> maybe if you add HLVM... ;-)
>
> > Well, now I'm thinking that the community should start a project like
> Parrot (with JIT optionally)
> > but dedicated to ML.
>
> I already did something like this called HLVM:
>
>  http://www.ffconsultancy.com/ocaml/hlvm/
>
> > The existing ocaml runtime is amazing but it's definitely not very
> community friendly and is in my
> > opinion a bit hard to understand given the scarcity of design documents.
>
> Feel free to ask me anything about HLVM's design. We have a dedicated
> mailing list:
>
>  https://lists.forge.ocamlcore.org/pipermail/hlvm-list/
>
> > A real community project with real documentation might be interesting for
> teaching purposes but also
> > in production environments.
>
> HLVM might be interesting for teaching purposes because it is tiny (2kLOC)
> and comprehensible whilst providing advanced features like JIT compilation
> (for a native-code REPL!) and a multicore-capable garbage collector (in
> only
> 100LOC!). HLVM should also be suitable for production environments.
>
> I had actually forgotten about the mincaml project but mincaml's front-end
> with HLVM's back-end sounds like a match made in heaven...
>
> Cheers,
> Jon.
>
>
>

[-- Attachment #2: Type: text/html, Size: 4958 bytes --]