Re: [Caml-list] Infix function composition operator

[Stephan Tolksdorf <st@sigmasquared.net>]

On Wed, Nov 10, 2010 at 17:41 -0000, Jon Harrop wrote:
> 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.

Your problem here seems to be the absence of compile-time 
meta-programming facilities in F#, not the limitations of parser 
combinators. Using a parser generator tool like ocamlyacc (which you 
originally cited as a better technology) wouldn't make the parsing in 
your situation any easier, or am I missing something?

In the case of your server application you could probably replace the 
compile-time meta-programming with some run-time reflection & code 
generation. If you cache serializers and deserializers per type, 
performance should still be good.

- Stephan

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