From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 72173BBAF for ; Wed, 10 Nov 2010 17:10:46 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcBAB5T2kxQQx8gkWdsb2JhbACDOZBJjjMVAQECCQsKBxEDH60LkH+BIoM1cwSNY4Ju X-IronPort-AV: E=Sophos;i="4.59,178,1288566000"; d="scan'208";a="77628436" Received: from smtprelay04.ispgateway.de ([80.67.31.32]) by mail4-smtp-sop.national.inria.fr with ESMTP; 10 Nov 2010 17:10:45 +0100 Received: from [188.193.144.210] (helo=[192.168.1.118]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PGDFz-000400-Px for caml-list@inria.fr; Wed, 10 Nov 2010 17:10:43 +0100 Message-ID: <4CDAC3FD.4010002@sigmasquared.net> Date: Wed, 10 Nov 2010 17:10:37 +0100 From: Stephan Tolksdorf User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: caml-list@inria.fr Subject: Re: [Caml-list] Infix function composition operator References: <1289396667803@names.co.uk> <022001cb80e1$6afeee00$40fcca00$@com> In-Reply-To: <022001cb80e1$6afeee00$40fcca00$@com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: postmaster@quanttec.com X-Spam: no; 0.00; infix:01 parser:01 combinators:01 ocamlyacc:01 camlp:01 ocaml:01 parser:01 combinators:01 compiler:01 annotations:01 cheers:01 yminsky:01 infix:01 ocaml's:01 ocaml:01 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 >> 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 >