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
>
next prev parent 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