On Friday 27 August 2004 04:38 am, Nicolas Cannasse wrote:
> 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.

In my experience, my OCaml code is three to five times faster than my 
Python code.  Yet my Python code is still perfectly usable and I'm fine 
with its speed.

While there are plenty of places where every last bit of performance is 
vital, there are also plenty of places (I dare say even more) where 
it's simply not an important consideration, and things like developer 
productivity, bug-free code, or ease of distribution really shine.

[ snip ]

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

As an example, my OfflineIMAP program is written in Python and uses a 
configuration file.  Some options in the configuration file actually 
take snippets of Python code; for instance, those that filter 
selections or perform transformations on folder names.  The latter 
actually takes a full Python function (defined with Python's "lamda" 
form.)  I investigated doing this in OCaml, figuring that since there 
is a toplevel interpreter that can do this stuff, it should be 
possible.  But there seems to be no way to do it.

-- John

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