caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Stephan Tolksdorf <st@sigmasquared.net>
To: caml-list@inria.fr
Subject: Re: [Caml-list] Infix function composition operator
Date: Wed, 10 Nov 2010 17:10:37 +0100	[thread overview]
Message-ID: <4CDAC3FD.4010002@sigmasquared.net> (raw)
In-Reply-To: <022001cb80e1$6afeee00$40fcca00$@com>

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
>


  reply	other threads:[~2010-11-10 16:10 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-10 13:44 mark
2010-11-10 14:13 ` Jon Harrop
2010-11-10 16:10   ` Stephan Tolksdorf [this message]
2010-11-10 17:41     ` Jon Harrop
2010-11-10 18:52       ` Stephan Tolksdorf
  -- strict thread matches above, loose matches on Subject: below --
2010-11-10 15:18 mark
2010-11-10  6:59 mark
2010-11-10 12:51 ` Jon Harrop
2010-11-14 18:20   ` Till Varoquaux
2010-11-10  3:19 Arlen Christian Mart Cuss
2010-11-10  3:45 ` [Caml-list] " Yaron Minsky
2010-11-10  4:37   ` Arlen Christian Mart Cuss
2010-11-10 10:06   ` DS
2010-11-10 13:23 ` Michael Ekstrand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CDAC3FD.4010002@sigmasquared.net \
    --to=st@sigmasquared.net \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).