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-boun...@yquem.inria.fr [mailto:caml-list- > boun...@yquem.inria.fr] On Behalf Of Stephan Tolksdorf > Sent: 10 November 2010 16:11 > To: caml-l...@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: m...@proof-technologies.com [mailto:m...@proof- > technologies.com] > >> Sent: 10 November 2010 13:44 > >> To: jonathandeanhar...@googlemail.com; ymin...@gmail.com; > >> ar...@noblesamurai.com > >> Cc: caml-l...@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<jonathandeanhar...@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-boun...@yquem.inria.fr [mailto:caml-list- > >>>> boun...@yquem.inria.fr] On Behalf Of m...@proof-technologies.com > >>>> Sent: 10 November 2010 07:00 > >>>> To: ymin...@gmail.com; ar...@noblesamurai.com > >>>> Cc: caml-l...@inria.fr > >>>> Subject: Re: [Caml-list] Infix function composition operator > >>>> > >>>> on 10/11/10 3:45 AM, ymin...@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 _______________________________________________ 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
