caml-list - the Caml user's mailing list
 help / Atom feed
From: Andreas Rossberg <rossberg@mpi-sws.org>
To: Gabriel Scherer <gabriel.scherer@gmail.com>
Cc: Alain Frisch <alain.frisch@lexifi.com>, caml users <caml-list@inria.fr>
Subject: Re: [Caml-list] Newbie comment on constructor syntax
Date: Mon, 9 Nov 2015 23:27:08 +0100
Message-ID: <95AE93FB-4D5A-43E2-B72F-40C348403AA6@mpi-sws.org> (raw)
In-Reply-To: <CAPFanBFze3PvO2JTSWByJUOyoYi-heb-pikQeHSsL_jKd3JecA@mail.gmail.com>


> On Nov 9, 2015, at 22:11 , Gabriel Scherer <gabriel.scherer@gmail.com> wrote:
> 
> On Mon, Nov 9, 2015 at 7:16 PM, Andreas Rossberg <rossberg@mpi-sws.org> 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.

That is already the case for some other patterns, e.g. matching float-only records, isn’t it?

> 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 haven’t yet used the new records in datatypes feature, but I assume the above would involve to distinct nominal types, so there is no reason to assume them compatible.

> 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.)

I am not fond of the revised syntax, because it does not explain why the term-level syntax for constructor application uses tuple notation.

It seems to me that tuples are already engrained in the current syntax and semantics. I doubt it will ever be realistically possible to change their meaning. If you want currying, then the backwards-compatible way would be introducing curried constructors as a new form, in addition to tupled ones. They would have a different type, and nothing would be particularly wrong with that! I would sign a petition for such an extension immediately. :)

/Andreas

> 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 <rossberg@mpi-sws.org> 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 <alain.frisch@lexifi.com>
>>> 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
>> 
>> 
> 
> -- 
> 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


  parent reply index

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-06  9:33 Soegtrop, Michael
2015-11-06 10:04 ` Nicolas Ojeda Bar
2015-11-06 10:31 ` Francois Berenger
2015-11-06 12:20   ` Soegtrop, Michael
2015-11-06 12:34     ` Gabriel Scherer
2015-11-06 13:09       ` Soegtrop, Michael
2015-11-06 14:10         ` Ashish Agarwal
2015-11-06 15:19           ` Soegtrop, Michael
2015-11-06 15:22             ` Ashish Agarwal
2015-11-21 17:24       ` [Caml-list] Notation for currying Hendrik Boom
2015-11-21 17:42         ` Gabriel Scherer
2015-11-21 18:06         ` David Rajchenbach-Teller
2015-11-21 18:56           ` Gabriel Scherer
2015-11-06 12:29 ` [Caml-list] Newbie comment on constructor syntax Jonas Jensen
2015-11-06 12:46   ` Soegtrop, Michael
2015-11-06 12:55     ` Gabriel Scherer
2015-11-08 21:17 ` Florian Weimer
2015-11-08 22:51   ` Norman Hardy
2015-11-09  6:27     ` Florian Weimer
2015-11-09 13:27       ` Stefan Monnier
2015-11-09  8:10     ` Soegtrop, Michael
2015-11-09 10:00       ` Hendrik Boom
2015-11-09 10:17       ` Alain Frisch
2015-11-09 10:35         ` Andreas Rossberg
2015-11-09 12:28           ` Alain Frisch
2015-11-09 17:33           ` Alain Frisch
2015-11-09 18:09             ` Gabriel Scherer
2015-11-09 18:16               ` Andreas Rossberg
2015-11-09 21:12                 ` Gabriel Scherer
2015-11-09 22:06                   ` Alain Frisch
2015-11-09 22:27                   ` Andreas Rossberg [this message]
2015-11-09 22:57                     ` Jeremy Yallop
2015-11-10  0:11                   ` Hendrik Boom
2015-11-10  8:27                   ` Soegtrop, Michael
2015-11-10 10:26                     ` Romain Bardou
2015-11-10 10:44                       ` Alain Frisch
2015-11-10 10:55                         ` Romain Bardou
2015-11-10 13:17                           ` Alain Frisch
2015-11-10 13:41                             ` Romain Bardou
2015-11-10 14:01                               ` Alain Frisch
2015-11-13 15:36                           ` Romain Bardou
2015-11-10 11:17                         ` Soegtrop, Michael
2015-11-10 14:11                     ` Hendrik Boom
2015-11-10 14:40                       ` immanuel litzroth
2015-11-10 15:30                       ` Soegtrop, Michael
2015-11-10 17:28                         ` Gerd Stolpmann
2015-11-09 20:32               ` Alain Frisch

Reply instructions:

You may reply publically 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=95AE93FB-4D5A-43E2-B72F-40C348403AA6@mpi-sws.org \
    --to=rossberg@mpi-sws.org \
    --cc=alain.frisch@lexifi.com \
    --cc=caml-list@inria.fr \
    --cc=gabriel.scherer@gmail.com \
    /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

caml-list - the Caml user's mailing list

Archives are clonable: git clone --mirror https://inbox.ocaml.org/caml-list

AGPL code for this site: git clone https://public-inbox.org/ public-inbox