RE: [Caml-list] Infix function composition operator

[Jon Harrop <jonathandeanharrop@googlemail.com>]

I am currently writing a concurrent server under contract in F#. Due to the poor performance of the default .NET serialization (over 170x slower than Marshal in OCaml!), I had to completely replace the serialization layer. Ideally, I would just write a script to compile my type definitions into serializers and deserializers over them. However, I haven't found time to do that yet so I am maintaining a set of combinators instead. They account for over 15% of the source code now. Every time I change a type (e.g. adding a field to a record type), I must update the combinators to reflect the changes. This is getting seriously tedious as the project is experimental and my types need to evolve rapidly.

If I were using OCaml, Marshal would be easily fast enough and I wouldn't even need to update my type definitions by hand because I could use structural typing (polymorphic variants and objects). Unfortunately, this is not yet possible in F#. Another problem area has been the incrementality of garbage collection. OCaml is good in this respect among functional languages but still orders of magnitude behind the state-of-the-art. With enough care and attention, .NET can be almost as good as OCaml is ordinarily but .NET's worse cases are horrific:

  http://flyingfrogblog.blogspot.com/2010/10/can-you-repro-this-64-bit-net-gc-bug.html

Cheers,
Jon.

> -----Original Message-----
> From: caml-list-bounces@yquem.inria.fr [mailto:caml-list-
> bounces@yquem.inria.fr] On Behalf Of Stephan Tolksdorf
> Sent: 10 November 2010 16:11
> To: caml-list@inria.fr
> Subject: Re: [Caml-list] Infix function composition operator
> 
> On Wed, Nov 10, 2010 at 14:13 -0000, Jon Harrop wrote:
> > However, I don't see it as a useful advantage in practice because
> parser combinators are so tedious during development (they require
> constant attention as types evolve): you want code generation like
> ocamlyacc or camlp4. OCaml is a very strong contender here, of course.
> 
> Could you maybe elaborate a bit on what you find tedious with regard to
> evolving types in the context of parser combinators?
> 
> In my parser code (using FParsec in F#) most types get inferred by the
> compiler and in the remaining instances the type annotations can hardly
> be called tedious. Actually, I find the types and the Visual Studio
> tooltips with the inferred types rather helpful for development.
> 
> - Stephan
> 
> >
> > Cheers,
> > Jon.
> >
> >> -----Original Message-----
> >> From: mark@proof-technologies.com [mailto:mark@proof-
> technologies.com]
> >> Sent: 10 November 2010 13:44
> >> To: jonathandeanharrop@googlemail.com; yminsky@gmail.com;
> >> arlen@noblesamurai.com
> >> Cc: caml-list@inria.fr
> >> Subject: Re: [Caml-list] Infix function composition operator
> >>
> >> So how does value restriction affect things here?  (excuse my lack
> of
> >> knowledge)
> >>
> >> One thing about using a pipeline like this is that it relies on '|>'
> >> being
> >> left-associative (which it is due to OCaml's convention on operators
> >> that
> >> start with "|").
> >>
> >> Mark.
> >>
> >>
> >> on 10/11/10 12:52 PM, Jon Harrop<jonathandeanharrop@googlemail.com>
> >> wrote:
> >>
> >>> A pipeline operator is usually preferred over function composition
> in
> >> impure
> >>> languages like OCaml and F# due to the value restriction. For
> >> example,
> >> your
> >>> example would be written in F# as:
> >>>
> >>> x |>  op1 |>  op2 |>  op3 |>  op4 |>  op5
> >>>
> >>> This style is very common in F#, particularly when dealing with
> >> collections.
> >>>
> >>> Cheers,
> >>> Jon.
> >>>
> >>>> -----Original Message-----
> >>>> From: caml-list-bounces@yquem.inria.fr [mailto:caml-list-
> >>>> bounces@yquem.inria.fr] On Behalf Of mark@proof-technologies.com
> >>>> Sent: 10 November 2010 07:00
> >>>> To: yminsky@gmail.com; arlen@noblesamurai.com
> >>>> Cc: caml-list@inria.fr
> >>>> Subject: Re: [Caml-list] Infix function composition operator
> >>>>
> >>>> on 10/11/10 3:45 AM, yminsky@gmail.com wrote:
> >>>>
> >>>>> This is probably a minority opinion, but I have written and read
> >>>> quite a
> >>>> lot
> >>>>> of OCaml code over the years, and I've seen surprisingly few
> >>>> effective
> >>>> uses
> >>>>> of the composition operator.  Somehow, I usually find that code
> >> that
> >>>> avoids
> >>>>> it is simpler and easier to read.
> >>>>
> >>>> I agree that using a composition operator can make the code
> obtuse,
> >> and
> >>>> so
> >>>> should not be overused.  But it's incredibly useful for certain
> >>>> situations:
> >>>>
> >>>> 1) If you are performing a long chain of composed operations, it
> >> avoids
> >>>> nested bracketing piling up.
> >>>>
> >>>> For example:
> >>>>        (op5<<- op4<<- op3<<- op2<<- op1) x
> >>>> Instead of:
> >>>>        op5 (op4 (op3 (op2 (op1 x))))
> >>>>
> >>>> This sort of thing happens quite a lot in certain applications,
> e.g.
> >> in
> >>>> language processing, to get at subexpressions.
> >>>>
> >>>> 2) Creating an anonymous function to be passed as an argument, it
> >>>> avoids
> >>>> explicitly mentioning arguments of that function.
> >>>>
> >>>> This sort of thing can happen a lot in functional programming
> >>>> generally.
> >>>>
> >>>> For example:
> >>>>        List.map (op2<<- op1) xs
> >>>> Instead of:
> >>>>        List.map (fun x ->  op2 (op1 x)) xs
> >>>>
> >>>> Mark Adams
> >>>>
> >>>> _______________________________________________
> >>>> 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
> >>>
> >>>
> >>>
> >>>
> >
> > _______________________________________________
> > 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
> >
> 
> _______________________________________________
> 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