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

[Gabriel Scherer <gabriel.scherer@gmail.com>]

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.

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