Re: [Caml-list] Newbie comment on constructor syntax

[Andreas Rossberg <rossberg@mpi-sws.org>]

> 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