Re: [Caml-list] Alternative Bytecodes for OCaml

["Nicolas Cannasse" <warplayer@free.fr>]

> > I agree with you here, the main problems OCaml and other functionnal
> > languages targeting CLR faces here are interoperability and
> > performances.
>
> No arguments here, but I would like to expand a but on the performance
> issue.  I have every reason to believe you are right about it, but one
> important thing to remember is that it may not matter to many.  In
> other words, let's not fall prey to premature optimization.

I agree. I was talking of performances as one of the advanges coming from
technology leverage. But that's true it's not the best one : accessing to
many libraries or interfacing seamlessly with other languages are much more
powerful features that we can get when focusing on a particular runtime
system.

However, my point was that current (to-be-)mainstream runtime systems (.NET
CLR and JVM) are not offering the best executation environements for
functional languages and we are then loosing some of the advanges the OO
languages are getting with no cost because theses VMs have been designed
with OO in mind. In the long term, that might be quite a big handicap for
functional languages not to be able to keep up in terms of performances or
easiness of interoperability when compared to OO languages.

> > Ocaml is great for writing DSL, and have both very efficient bytecode
> > and nativecode compilers. However theses two technologies are right
> > now reserved to OCaml itself.  If they were more "opened" (means :
> > documented, provide API and tools to ease code generation, ...) , it
>
> I'm not 100% certain what you're talking about here, but I'll guess and
> try to share my thoughts along those lines :-)
>
> There is a lot of great stuff in camlp4.  It is, in my opinion, the
> single most powerful and unique part of OCaml.  I've dabbled with it
> myself, but there's a lot that's lacking, too.  Despite the tutorial
> and reference, the learning curve is quite steep due in part to the
> syntax and available parsers/lexers, and in part to the academic rather
> than how-to nature of the documents.
>
> Then there's a whole other part of OCaml that is untapped.  For
> instance, the OCaml source includes everything necessary to write, in
> OCaml, the toplevel interpreter.  However, the OCaml modules installed
> on the system don't provide enough for someone to embed an OCaml
> interpreter (aside from the interactive kind) or generic printer in
> their own code.  I think part of the problem could be solved simply by
> installing more bits of the OCaml distribution on people's systems.

That was part of my thinking. A lot of technologies that are available in
the OCaml compiler sources are not made accessible to the OCaml programmer.
I would like for instance be able to create on the fly Lambda OCaml AST,
generate corresponding ocaml bytecode, and execute it : such a feature would
be great for DSL since it will remove the need to implement an efficient
runtime system (ocaml one will be used in place).

Regards,
Nicolas Cannasse

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