Re: [Caml-list] [OSR] OCaml Standard Recommandation Process

[Jon Harrop <jon@ffconsultancy.com>]

On Monday 28 January 2008 22:05:30 Till Varoquaux wrote:
> It is worth noting that OCaml is not F#. Objects in OCaml, unlike in
> F#, are an advance feature, many users find them hard to grasp and
> work with. They also come with a rather high runtime cost. Unless we
> have a good reason to do so, I think we should avoid bolstering them
> at the very core of the standard library.

In this case, the user doesn't see anything at all of the objects.

> Don't get me wrong, I think objects have a purpose; and so have
> polymorphic variants and recursive modules but great care should be
> taken before axing the core library around them.

Absolutely. I couldn't agree more.

I would say exactly the same of working around the absence of a "try..finally" 
construct using combinators. The problem is that trivial tasks like reading 
lines from a file are made much more difficult for newbies because OCaml 
pulls in so many complicated concepts but this complexity is completely 
incidental, completely man-made. OCaml is better in the long-run, of course, 
but many languages solve these common problems much more elegantly than 
OCaml.

> We should keep complicated solutions for complicated problems.

Exactly but OCaml is moving in the opposite direction because it is a research 
project: it is getting more complicated.

The community would benefit enormously from lots of simple things like 
String.fold_right and a "try..finally" construct (I've no preference for 
those two, I'm just picking them out of hundreds of common ideas) but INRIA 
cannot afford to do such things themselves and are instead focussing on 
advanced research concepts like integrating generalized algebraic data types 
instead. That is great research, but it does not help people to use OCaml as 
a tool. Hence if the community wants this improved then they must improve it 
themselves. That means either forking OCaml or starting afresh.

> Although is is tempting to propose a solution for IO using phantom
> types, objects or whatnot, I still think the Common Lisp approach
> (using unwind_protect) is an elaborate enough one to avoid most
> problems whilst remaining simple enough to be viable.

Yes. The only difference is syntax and I think that is an important 
difference.

> A great solution in F# might not translate as well in OCaml, or it
> might not translate at all.

I was proposing that we learn from the advancements made in other languages 
rather than referring to porting F# code to OCaml code.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e