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 8595E7EEFA for ; Mon, 9 Nov 2015 22:12:12 +0100 (CET) IronPort-PHdr: 9a23:lFChOh0QFj7WMDM7smDT+DRfVm0co7zxezQtwd8ZsekWI/ad9pjvdHbS+e9qxAeQG96LtrQY0KGP7/uocFdDyKjCmUhKSIZLWR4BhJdetC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TWM5DIfUi/yKRBybrysXNWC0oLrjKvrp8abSj4LrQT+SIs6FA+xowTVu5teqqpZAYF19CH0pGBVcf9d32JiKAHbtR/94sCt4MwrqHwI6LoJvvRNWqTifqk+UacQTHF/azh0t/vQqALbQACTynwZW2QQ2loUUkmWpC39C773vjH3v/E14i6BJsf7V798DS6l9LxhRQXnoCIfNnsi73qRjdZ/2vF1uhWk8jN2yZTVbYXdD/F+c7nQZ5tOSmNLRMdcU2paCYOxdYYVJ+UENOdc6YL6og1d/lOFGQCwCba3mXdzjXjs0Ph/jr0s 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-f179.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.179; 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.179 as permitted sender) identity=mailfrom; client-ip=209.85.213.179; 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-f179.google.com) identity=helo; client-ip=209.85.213.179; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-ig0-f179.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AXBgDOCkFWlLPVVdFeg1o0LUIGrRqBT4UxjA8hgi6DQQKBPgc8EAEBAQEBAQEBEAEBAQEHCwsJHzCCLoIIAQEEEhEEGQEbEgsBAwwGBQsNAgIJHQICIgERAQUBChIGExIHCYd2AQMSDaMcgTE+MYtIgWqCeYZfChknAwpWg3MBAQEBAQEBAwEBAQEBARcBBQ5zhVOEfod1gUQFhgsMkDGFHogJgVtJg3eSOIIlEiSBFziCLyOBXj00hWYBAQE X-IPAS-Result: A0AXBgDOCkFWlLPVVdFeg1o0LUIGrRqBT4UxjA8hgi6DQQKBPgc8EAEBAQEBAQEBEAEBAQEHCwsJHzCCLoIIAQEEEhEEGQEbEgsBAwwGBQsNAgIJHQICIgERAQUBChIGExIHCYd2AQMSDaMcgTE+MYtIgWqCeYZfChknAwpWg3MBAQEBAQEBAwEBAQEBARcBBQ5zhVOEfod1gUQFhgsMkDGFHogJgVtJg3eSOIIlEiSBFziCLyOBXj00hWYBAQE X-IronPort-AV: E=Sophos;i="5.20,267,1444687200"; d="scan'208";a="186822678" Received: from mail-ig0-f179.google.com ([209.85.213.179]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 09 Nov 2015 22:12:11 +0100 Received: by igvg19 with SMTP id g19so35720461igv.1 for ; Mon, 09 Nov 2015 13:12:10 -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=02ahqVYA5lssbeKXxlFllF1uI2Ia7MZ5K9lvM4JQGzw=; b=EtBXOPMX+GhoFXAXj7N3KVx00pcnYvnfYzNgnWS5KE3Kag9KrlOe0cqmWVBNhgsi2/ Dq8k8nnUU4DG3EAg+ydXsJoJVxHZhUL5WUkNMm548W2f6FSH4tlhQlReJpZZ4WTstVEu 0jVY5DxiTg2E/5D+RuJQbMKgixx8cBMHMWSYiVCOuUU2yBPbxAldHTaWZtS0mwRp/50r 2BoiGfyhDFzqh9rNcnTj2+RIR98x+0VHHbLF70wG7+0REhNMx0MRCW6xLJkqtdXmQOcL rmiSwQ4EnzxP05FmHgWoi5ghamheOeIagG1R2LP3SiL8YrXNfv8R651Ff/Fosv51ko7V D7iQ== X-Received: by 10.50.160.6 with SMTP id xg6mr567383igb.38.1447103530366; Mon, 09 Nov 2015 13:12:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.39.200 with HTTP; Mon, 9 Nov 2015 13:11:30 -0800 (PST) In-Reply-To: <5640E2EF.7070400@mpi-sws.org> References: <0F7D3B1B3C4B894D824F5B822E3E5A172CE3E070@IRSMSX102.ger.corp.intel.com> <87pozk6vjp.fsf@mid.deneb.enyo.de> <0F7D3B1B3C4B894D824F5B822E3E5A172CE3E747@IRSMSX102.ger.corp.intel.com> <56407297.2060309@frisch.fr> <564076EA.7020805@mpi-sws.org> <5640D8E0.6060102@lexifi.com> <5640E2EF.7070400@mpi-sws.org> From: Gabriel Scherer Date: Mon, 9 Nov 2015 22:11:30 +0100 Message-ID: To: Andreas Rossberg Cc: Alain Frisch , caml users Content-Type: text/plain; charset=UTF-8 Subject: Re: [Caml-list] Newbie comment on constructor syntax On Mon, Nov 9, 2015 at 7:16 PM, Andreas Rossberg wrote: > Hm, I see your point, but don't you already introduce that problem (i.e., > commit to tuples) by allowing the `C x` sugar for n-ary constructors? > Because in a world of curried constructors, `x` would not be typed as the > tuple of arguments, but only as the first argument of the constructor. Yes, it is already problematic, and in fact I'm personally not completely convinced by this feature -- Alain it "reduces bad surprises for beginners", but I suspect that adding more magic in this place could not actually help that much -- at least the current semantic model is simple. Another problem with (C x) is the non-trivial performance implications of | C x -> x which actually allocates. The problem would only get worse if we allowed type t = { mutable x : int; mutable y : int } type u = Packed of { mutable x : int; mutable y : int } let pack x = Packed x with an observable change in mutability semantics from the same code with type u = Packed of t (but Alain has not suggested adding this feature to decrease surprises (yet?), and luckily our tuples are immutable.) I like the revised syntax choice of writing type t = A of int and int list instead of type t = A of int * int list which removes the beginner surprise without introducing other unpalatable design side-effects. (It is still awkward for GADTs, but such is life.) Sometime I think it's wise to avoid local improvements that get stuck in local maxima. (This is also my argument against Haskell's choice of using the same syntax for the pairs (x, y) and the types of pairs (t, u). I guess at the time they thought that, of course, they would never get type-level pairs.) On Mon, Nov 9, 2015 at 7:16 PM, Andreas Rossberg wrote: > On 11/09/2015 07:08 PM, Gabriel Scherer wrote: >> >> If we gave a functional semantic to the unapplied constructor, then I >> think that good taste would mandate for the application of this >> function and the application of the constructor to be equivalent. This >> means that by choosing a tuple-taking function, we commit to the >> tuple-application syntax (that nobody likes), and that choosing a >> currified function creates an unpleasant inconsistency in the >> language. >> >> I don't know whether we could ever manage to transition to a currified >> syntax for constructors, but right now it is at least conceivable >> because the application syntax is just a concrete syntax choice, it >> does not affect typing. Turning unapplied constructor into a function >> (tuplified or currified) makes it a typing property, observable at >> specification boundaries: we cannot change it. > > > Hm, I see your point, but don't you already introduce that problem (i.e., > commit to tuples) by allowing the `C x` sugar for n-ary constructors? > Because in a world of curried constructors, `x` would not be typed as the > tuple of arguments, but only as the first argument of the constructor. > > /Andreas > > > >> On Mon, Nov 9, 2015 at 6:33 PM, Alain Frisch >> wrote: >>> >>> On 09/11/2015 11:35, Andreas Rossberg wrote: >>>> >>>> >>>> Yes please, I would appreciate such sugar. >>> >>> >>> >>> I've now submitted a cleaner implementation, working on both expressions >>> and >>> patterns: >>> >>> https://github.com/ocaml/ocaml/pull/284 >>> >>>> Even more I would appreciate >>>> generalising that to allowing constructors to be used as first-class >>>> expressions (i.e., unapplied "C" -> "fun (x1,...,xN) -> C (x1,...,xN)" >>>> when C is a constructor with arity > 0). I had to write some AST mapping >>>> code recently that would have vastly benefited from that. >>> >>> >>> >>> This is not covered (and now, it could simply be "fun x -> C x" :-)). I >>> don't see anything clever to be done on patterns for "unapplied >>> constructors", though. >>> >>> >>> Alain >>> >>> >>> -- >>> 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 > >