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 A843A7EE25 for ; Fri, 25 Oct 2013 22:44:41 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of rathereasy@gmail.com) identity=pra; client-ip=209.85.220.45; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="rathereasy@gmail.com"; x-sender="rathereasy@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of rathereasy@gmail.com designates 209.85.220.45 as permitted sender) identity=mailfrom; client-ip=209.85.220.45; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="rathereasy@gmail.com"; x-sender="rathereasy@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-pa0-f45.google.com) identity=helo; client-ip=209.85.220.45; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="rathereasy@gmail.com"; x-sender="postmaster@mail-pa0-f45.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIDAG3XalLRVdwtlGdsb2JhbABZgz9Uq2mKGIhHgRsIFg4BAQEBBwsLCRIqgiUBAQQBJxkBGxILAQMBCwYFCwMKDSEiAREBBQEKEgYTCAqHYgEDCQYNmnyMVoMKhCAKGScDCmSJAQEFDI9DBAeELAOYCoEvjmwYKYRtIA X-IPAS-Result: AhIDAG3XalLRVdwtlGdsb2JhbABZgz9Uq2mKGIhHgRsIFg4BAQEBBwsLCRIqgiUBAQQBJxkBGxILAQMBCwYFCwMKDSEiAREBBQEKEgYTCAqHYgEDCQYNmnyMVoMKhCAKGScDCmSJAQEFDI9DBAeELAOYCoEvjmwYKYRtIA X-IronPort-AV: E=Sophos;i="4.93,573,1378850400"; d="scan'208";a="38833802" Received: from mail-pa0-f45.google.com ([209.85.220.45]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 25 Oct 2013 22:44:41 +0200 Received: by mail-pa0-f45.google.com with SMTP id kp14so4265556pab.4 for ; Fri, 25 Oct 2013 13:44:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GFUg8Bdc/fyAga/4PdZkHw2WuL6kH5ne6Fw6bKQvcB8=; b=kHPPHEVDhH7zFED9TLHkb5MrKlDKv7QCMN3Ee61i3nyKfZ+aZsiGqa5IglG+8Higoa EKK2ec3QIYEChwcOKi5hRBKlEbgrG4iwhuKvlGD6cqaGDl9E6IpWfMeaY+++L1IA8F3X 4OHbrSFBSo3JNzLmE4EGCUwVNvBKZI4VfuACVqZdV/Tqrs9170I1ytLfCAErZoVkA/Cj 1rWFFER2Fj8U+KQKinHRICIPjNcdDMbq62KxrYt8rlkUa2e12l/KFrgtW/DN/IpeY2H9 123y/BBGzrLS1xw7us+/lqANNba7+xddz49LeitJwaq8pndPl0mxpwzfA4DaEbPzPQu7 PS5g== MIME-Version: 1.0 X-Received: by 10.66.196.110 with SMTP id il14mr12633032pac.130.1382733878969; Fri, 25 Oct 2013 13:44:38 -0700 (PDT) Received: by 10.70.9.37 with HTTP; Fri, 25 Oct 2013 13:44:38 -0700 (PDT) In-Reply-To: References: <97627FCD-30E1-45AD-A72B-CD423170C0AC@math.nagoya-u.ac.jp> <20131025082911.GB23798@voyager> <878uxhd62p.fsf@golf.niidar.ru> <526A7F33.6040203@mpi-sws.org> Date: Fri, 25 Oct 2013 16:44:38 -0400 Message-ID: From: Jacques Le Normand To: Yaron Minsky Cc: Andreas Rossberg , Gabriel Scherer , Ivan Gotovchits , Roberto Di Cosmo , Jacques Garrigue , OCaML List Mailing Content-Type: multipart/alternative; boundary=047d7bf16572accd1404e996d1c9 Subject: Re: [Caml-list] Equality between abstract type definitions --047d7bf16572accd1404e996d1c9 Content-Type: text/plain; charset=ISO-8859-1 I'm surprised noone has pointed out the new type annotation syntax: let id : type s. s -> s = fun x -> x On Fri, Oct 25, 2013 at 4:32 PM, Yaron Minsky wrote: > Changing the semantics of this will, I think, break a _lot_ of code. > I for one am not excited to do so. > > For what it's worth, I suspect that most people who are surprised by > this are people who were trained on Standard ML. At Jane Street we've > had a lot of people learn the language, and the complaints I've heard > about this feature are, I think, mostly from that group. > > I also don't find Andreas suggestion particularly intuitive. I would > have guessed that (x: '_a) would constrain x to be a weakly > polymorphic value, which is at odds with the proposal. > > y > > On Fri, Oct 25, 2013 at 10:24 AM, Andreas Rossberg > wrote: > > On 10/25/2013 01:09 PM, Gabriel Scherer wrote: > >> > >> However, I think that the current syntax of implicitly-introduced > >> variables with heuristically-defined scoping rules is bad in any case. > >> My own toy experiment with explicit syntaxes always use an explicit > >> binding syntax for both rigid and flexible variables (eg. "forall a b c > >> in ..." and "some a b c in ..."). In this regard, the ('a 'b . ty) or > >> (type a) syntaxes are definite improvements -- if only we had applied > >> those explicit binding forms to GADT constructor types as well... So I > >> think that even with Andreas' proposed change, people would still be > >> surprised by things like the following: > >> > >> let id : 'a -> 'a = fun x -> x > >> > >> let dup (x : 'a) ('a * 'a) = > >> let result = (x, x) in > >> (id : 'a -> 'a) result (* fails, while (id : 'b -> 'b) works *) > > > > > > Yes, I agree that implicit scoping is a bit of an ugly hack. That said, I > > don't expect anybody to be truly surprised about the example above. At > least > > I never heard this being an issue for SML programmers. People probably > > hardly ever write anything like the above, or avoid shadowing for clarity > > anyway. > > > > /Andreas > > > > > > > > -- > > 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 > --047d7bf16572accd1404e996d1c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm surprised noone has pointed out the new type annot= ation syntax:

let id : type s. s -> s =3D fun x ->= x


On Fri, Oct 25, 2013 at 4:32 PM, Yaron Minsky <yminsky@janestreet.co= m> wrote:
Changing the semantics of this will, I think= , break a _lot_ of code.
I for one am not excited to do so.

For what it's worth, I suspect that most people who are surprised by
this are people who were trained on Standard ML. =A0At Jane Street we'v= e
had a lot of people learn the language, and the complaints I've heard about this feature are, I think, mostly from that group.

I also don't find Andreas suggestion particularly intuitive. =A0I would=
have guessed that (x: '_a) would constrain x to be a weakly
polymorphic value, which is at odds with the proposal.

y

On Fri, Oct 25, 2013 at 10:24 AM, Andreas Rossberg <rossberg@mpi-sws.org> wrote:
> On 10/25/2013 01:09 PM, Gabriel Scherer wrote:
>>
>> However, I think that the current syntax of implicitly-introduced<= br> >> variables with heuristically-defined scoping rules is bad in any c= ase.
>> My own toy experiment with explicit syntaxes always use an explici= t
>> binding syntax for both rigid and flexible variables (eg. "fo= rall a b c
>> in ..." and "some a b c in ..."). In this regard, t= he ('a 'b . ty) or
>> (type a) syntaxes are definite improvements -- if only we had appl= ied
>> those explicit binding forms to GADT constructor types as well... = So I
>> think that even with Andreas' proposed change, people would st= ill be
>> surprised by things like the following:
>>
>> =A0 =A0let id : 'a -> 'a =3D fun x -> x
>>
>> =A0 =A0let dup (x : 'a) ('a * 'a) =3D
>> =A0 =A0 =A0let result =3D (x, x) in
>> =A0 =A0 =A0(id : 'a -> 'a) result =A0(* fails, while (i= d : 'b -> 'b) works *)
>
>
> Yes, I agree that implicit scoping is a bit of an ugly hack. That said= , I
> don't expect anybody to be truly surprised about the example above= . At least
> I never heard this being an issue for SML programmers. People probably=
> hardly ever write anything like the above, or avoid shadowing for clar= ity
> anyway.
>
> /Andreas
>
>
>
> --
> Caml-list mailing list. =A0Subscription 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. =A0Subscription management and archives:
ht= tps://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

--047d7bf16572accd1404e996d1c9--