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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 953E9BBAF for ; Wed, 10 Nov 2010 18:42:11 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgBADdo2kxKfVK2kGdsb2JhbACDOZBKgVSMUAgVAQECCQkMBxEDH6QviSSCVAEFjigBBIEigWIIgUtzkFU X-IronPort-AV: E=Sophos;i="4.59,178,1288566000"; d="scan'208";a="65427659" Received: from mail-wy0-f182.google.com ([74.125.82.182]) by mail3-smtp-sop.national.inria.fr with ESMTP; 10 Nov 2010 18:42:10 +0100 Received: by wya21 with SMTP id 21so1003095wya.27 for ; Wed, 10 Nov 2010 09:42:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:organization:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=ppoivKBWE4wu9mcVIJjDATTFcW4wRWamfFAcFxpUJKY=; b=W3XsYdIqv0L9/Z4ANuf0JKrNfr/JyKWF+lCz0EAmZm2jwg32myeTjFlQdJqnDT0q77 Sn6rMqqTMCTcOtVOZvblF0D7JL88TobsiPzW5GH2gBL8uND+0U/eLFCSYFvx6Wso60BH K7YYdIz9fNynd6QenXrdHcOymvTd8+AJjTe1o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:organization:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=RKNyX4TWDfQTwXLVEbHJ7QzOs+3z7PDIN8eaj3RUVE1o3GA8Rq77TcRk+AEkacT2Hm zgAmfVoC1GSeNokIxa+OmLYi+5PVv0Wuc5CalWtIakMQMpn4jEHaTg7wO01xGR92YGIn 63livjy/n8c3qdwKgVvhAR5uBUDBU79CLuOgc= Received: by 10.227.135.85 with SMTP id m21mr8744530wbt.227.1289410929454; Wed, 10 Nov 2010 09:42:09 -0800 (PST) Received: from WinEight ([87.112.186.137]) by mx.google.com with ESMTPS id h29sm812697wbc.21.2010.11.10.09.42.07 (version=SSLv3 cipher=RC4-MD5); Wed, 10 Nov 2010 09:42:08 -0800 (PST) From: Jon Harrop To: "'Stephan Tolksdorf'" , References: <1289396667803@names.co.uk> <022001cb80e1$6afeee00$40fcca00$@com> <4CDAC3FD.4010002@sigmasquared.net> In-Reply-To: <4CDAC3FD.4010002@sigmasquared.net> Subject: RE: [Caml-list] Infix function composition operator Date: Wed, 10 Nov 2010 17:41:45 -0000 Organization: Flying Frog Consultancy Message-ID: <024901cb80fe$8c1adb90$a45092b0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuA8eqBM/ELQIUYQ4um0rzzN5kjDAACy/xA Content-Language: en-gb X-Spam: no; 0.00; infix:01 ocaml:01 combinators:01 combinators:01 ocaml:01 variants:01 cheers:01 infix:01 parser:01 ocamlyacc:01 camlp:01 parser:01 compiler:01 annotations:01 cheers:01 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-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 >=20 > 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. >=20 > Could you maybe elaborate a bit on what you find tedious with regard = to > evolving types in the context of parser combinators? >=20 > 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. >=20 > - Stephan >=20 > > > > 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 > > >=20 > _______________________________________________ > 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