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

["Till Varoquaux" <till.varoquaux@gmail.com>]

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.
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.
Out of the so called "advanced" features of OCaml only the labelled
and optional arguments have made their way in the standard library. As
much as we all enjoy re-inventing the standard library around a nice
cold beer, we have to give credit to the INRIA's team for their
collective wit and the work that actually has been done.
We should keep complicated solutions for complicated problems.
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.

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

On Jan 28, 2008 8:49 PM, Jon Harrop <jon@ffconsultancy.com> wrote:
> On Monday 28 January 2008 16:06:10 Christophe TROESTLER wrote:
> > On Mon, 28 Jan 2008 15:25:12 +0000, Jon Harrop wrote:
> > > So you write a "use" binding:
> > >
> > >   let read_first_line file =
> > >     use ch = open_in file in
> > >     input_line ch
> > >
> > > and it gets translated into:
> > >
> > >   let read_first_line file =
> > >     let ch = open_in file in
> > >     try input_line ch finally
> > >     ch#dispose
> > >
> > > where the "dispose" method that was automatically inserted at the end of
> > > the scope of the "use" binding calls "close_in" in this case to
> > > deallocate the external resource (a file handle in this case but it could
> > > be anything with a dispose method).
> >
> > What is wrong with
> >
> >    let read_first_line file =
> >      with_open_in file begin fun ch ->
> >        input_line ch
> >      end
>
> Sure. Here's the complete version using combinators as a workaround:
>
> # let try_finally x f g =
>     try
>       let f_x = f x in
>       g x;
>       f_x
>     with e ->
>       (try g x with _ -> ());
>       raise e;;
> val try_finally : 'a -> ('a -> 'b) -> ('a -> unit) -> 'b = <fun>
>
> # let with_open_in file k =
>     try_finally (open_in file) k close_in;;
> val with_open_in : string -> (in_channel -> 'a) -> 'a = <fun>
>
> # let read_first_line file =
>     with_open_in file begin fun ch ->
>       input_line ch
>     end;;
> val read_first_line : string -> string = <fun>
>
> This is almost exactly what I currently do.
>
> The "use" binding is syntactic sugar to make it shorter, clearer, more generic
> and scale better.
>
> I'd be more than happy to have anything at all added to improve this though.
> Combinators in the stdlib are certainly better than nothing and this is one
> of the most complained about noob problems (and lack of functions to read
> files)...
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.
> http://www.ffconsultancy.com/products/?e
>
> _______________________________________________
>
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>



-- 
http://till-varoquaux.blogspot.com/