From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id DB9A37FD3B for ; Sat, 21 Nov 2015 19:56:06 +0100 (CET) IronPort-PHdr: 9a23:olihiRNq/Sw8z7IhaZYl6mtUPXoX/o7sNwtQ0KIMzox0KPX4rarrMEGX3/hxlliBBdydsKIZzbSJ+PG9EUU7or+/81k6OKRWUBEEjchE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i760zceF13FOBZvIaytQ8iJ35nxib/5qsCbSj4LrQT+SIs6FA+xowTVu5teqqpZAYF19CH0pGBVcf9d32JiKAHbtR/94sCt4MwrqHwI6LoJvvRNWqTifqk+UacQTHF/azh0t/vQqALbQACTynwZW2QQ2loUUkmWpC39C7v4rCr28NZw3C2XJ+X7S6txXSWl6eFsUhC7pj0AMmsW+WvNi8F0xJlQoB+7qgY3l4HdapuUOf44ZajdcMkXX0JOW89QU2pKBYbqPNhHNPYIIesN99q1nFAJtxbrQFT1CQ== Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=gabriel.scherer@gmail.com; spf=Pass smtp.mailfrom=gabriel.scherer@gmail.com; spf=None smtp.helo=postmaster@mail-ig0-f176.google.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.213.176; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.213.176 as permitted sender) identity=mailfrom; client-ip=209.85.213.176; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ig0-f176.google.com) identity=helo; client-ip=209.85.213.176; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-ig0-f176.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AWAQDSvVBWm7DVVdFeFoNENG8GryyFOIwaI4VsAoEoBzwQAQEBAQEBAQEQAQEBAQEGCwsJIS6CLYIIAQEEDgQRBBkBGwkJCwEDDAYFCw0CAgkdAgIiAREBBQEKEhkJCRCHdgEDEg2hcYExPjGLSIFqgnmFQwoZJwMKVoQZAQEBAQEBBAEBAQEBARcBBQ5zhVOEfoJxhQSBRAWGDgyHBIVNg2WFJIgNgVtJkmGDVIIlEiSBFziCLyOBXj00AQEBhSgBAQE X-IPAS-Result: A0AWAQDSvVBWm7DVVdFeFoNENG8GryyFOIwaI4VsAoEoBzwQAQEBAQEBAQEQAQEBAQEGCwsJIS6CLYIIAQEEDgQRBBkBGwkJCwEDDAYFCw0CAgkdAgIiAREBBQEKEhkJCRCHdgEDEg2hcYExPjGLSIFqgnmFQwoZJwMKVoQZAQEBAQEBBAEBAQEBARcBBQ5zhVOEfoJxhQSBRAWGDgyHBIVNg2WFJIgNgVtJkmGDVIIlEiSBFziCLyOBXj00AQEBhSgBAQE X-IronPort-AV: E=Sophos;i="5.20,329,1444687200"; d="scan'208";a="188540013" Received: from mail-ig0-f176.google.com ([209.85.213.176]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 21 Nov 2015 19:56:05 +0100 Received: by igbxm8 with SMTP id xm8so33435963igb.1 for ; Sat, 21 Nov 2015 10:56:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yZqLsKAL3pVmixaJzURCjXC8Gul1zvCCeL839kaDdnA=; b=QzFIl+XHOO9bldnorjpYaPfex7IfN3P90z+UtTE6Q/Xhnma3AiIzCjx5BtlNcCJVkZ 7oVIrndRHn5rdEid3PpKYC3t5DZKPwwAwPQEoNConshfRo7Ayu0OHXXVi3MhN6tVjps0 +rgk7tkrTVWnAlEpIdZcPd+dSoyiz7oCoBYPhMJ1DA7wiUlG7K2xe25AhtvjlROPg+Ie 0lvptTe+xg7eHH/5waOnmZH2wnSaLOzl+CxmpLPRftlJNgncL1KXE1ntWdMV/0cQZLFk YpdSXKRARJZKsjMWlBZHGcEm5YDZZefqD60bBo80sIVNmn3VXst+fBRhEUX4K/447loZ UTgw== X-Received: by 10.50.73.228 with SMTP id o4mr5617489igv.37.1448132164547; Sat, 21 Nov 2015 10:56:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.39.200 with HTTP; Sat, 21 Nov 2015 10:55:25 -0800 (PST) In-Reply-To: <5650B27F.5000701@ens-lyon.org> References: <0F7D3B1B3C4B894D824F5B822E3E5A172CE3E070@IRSMSX102.ger.corp.intel.com> <563C816B.7020604@inria.fr> <0F7D3B1B3C4B894D824F5B822E3E5A172CE3E0E1@IRSMSX102.ger.corp.intel.com> <20151121172401.GA31756@topoi.pooq.com> <5650B27F.5000701@ens-lyon.org> From: Gabriel Scherer Date: Sat, 21 Nov 2015 19:55:25 +0100 Message-ID: To: David.Teller@ens-lyon.org Cc: Hendrik Boom , caml users Content-Type: text/plain; charset=UTF-8 Subject: Re: [Caml-list] Notation for currying The initial discussion was more about the difference in readability between two syntaxes for fully-applied functions or constructors, f(x, y, z), C(x, y, z) or f x y z, C x y z I find the latter more readable in many settings, in particular where functions or constructors are nested. One typical example would be the "balance" functions for Okasaki-inspired red-black trees, for example https://www.lri.fr/~filliatr/ftp/ocaml/ds/rbset.ml.html Compare | Red (Red (a,x,b), y, c), z, d -> Red (Black (a,x,b), y, Black (c,z,d)) with | (Red (Red a x b) y c), z, d Red (Black a x b) y (Black c z d) Note that using this syntax does not in itself require supporting partial application, even though they are naturally linked in the most common reading of this syntax as nested unary application. Now, to your question of "do we need to make it easy to partially abstract over the last parameter of the function", I think I would agree with you that this is not essential (especially when the syntax for abstraction is already lightweight). However, having a good syntax for application is a rather subtle balance to strike that may require cooperation of several distinct syntactic elements -- in particular when you also want to support named parameters (or have a lightweight enough syntax for records or named tuples that looks like named parameters). I like named parameters as they often improve the robustness of APIs -- lightweight records are even better because they can be both passed and returned. Finally, in Mezzo ( http://protz.github.io/mezzo/ ) there is a cute trick that I have not seen anywhere else, and I wonder whether it is an extraordinary (but ancedotal) coincidence or something that should be reused. The syntax for function parameters in function prototypes (declarations, signature items) val concat: [a] (consumes list a, consumes list a) -> (list a) and in function definitions val concat [a] (consumes xs: list a, consumes ys: list a): list a = ... is exactly the same. (See http://protz.github.io/mezzo/tutorial/tutorial.html.pp.html#function-types , http://protz.github.io/mezzo/tutorial/tutorial.html.pp.html#function-definitions ) This is only possible because the language has just enough dependent types to make it natural to name all function parameters in their types, and even do deep pattern-matching on an argument directly from the type definition. It reminds us of the strange identification between types and patterns in CDuce ( http://www.cduce.org/ ). On Sat, Nov 21, 2015 at 7:05 PM, David Rajchenbach-Teller wrote: > As a side question, is currying really an important language feature? In > my experience, it hinders readability and makes it harder to reason > about types ("wait, is it weakly or strongly polymorphic? exactly which > type variables were generalized?") > > After coding a number of years in languages without currying, I haven't > found myself lacking this feature a single time. > > Cheers, > David > > On 21/11/15 18:24, Hendrik Boom wrote: >> On Fri, Nov 06, 2015 at 01:34:11PM +0100, Gabriel Scherer wrote: >>> >>> I personally believe that currified constructor syntax would be a better >>> choice, and that using non-currified constructors is a historical mistake >>> of SML/Caml. But I am also not convinced that efforts to change it today >>> are worth the trouble, and prefer to concentrate on improving other parts >>> of the OCaml ecosystem. >> >> Perhaps there should be explicit syntax for currying, such as >> f a b _ >> instead of >> f a b >> That would permit currying in other argument positions: >> f a _ c >> though I suspect _ may be the wrong symbol for the current language, and >> I also suspect it's far too late tointroduce it in the current language. >> >> I have noticed that almost a the situations where the compiler thinks I >> mean to curry I actually just left out a parameter by mistake. The type >> inferences it makes based on these errors usually occur elsewhere and >> are truly mystifying. >> >> -- hendrik >> > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs