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 347597EE25 for ; Sun, 27 Oct 2013 15:43:24 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of yminsky@janestreet.com) identity=pra; client-ip=38.105.200.229; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="yminsky@janestreet.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of yminsky@janestreet.com designates 38.105.200.229 as permitted sender) identity=mailfrom; client-ip=38.105.200.229; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="yminsky@janestreet.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@tot-dmz-mxout1.janestreet.com) identity=helo; client-ip=38.105.200.229; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="postmaster@tot-dmz-mxout1.janestreet.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtgGANclbVImacjlnGdsb2JhbABZgXECAYFLVKwAkl+BFB4OAQEBAQEGFgk8giUBAQUnGQEBLAsBDwsLDQ0hIQESAQUBChIGExKHYwMPAwIImUWLDYRTAQWEOQMKiWUGjGWCcAeELJYigWuBL4shg0sYKYRt X-IPAS-Result: AtgGANclbVImacjlnGdsb2JhbABZgXECAYFLVKwAkl+BFB4OAQEBAQEGFgk8giUBAQUnGQEBLAsBDwsLDQ0hIQESAQUBChIGExKHYwMPAwIImUWLDYRTAQWEOQMKiWUGjGWCcAeELJYigWuBL4shg0sYKYRt X-IronPort-AV: E=Sophos;i="4.93,580,1378850400"; d="scan'208";a="39014170" Received: from mx5.janestreet.com (HELO tot-dmz-mxout1.janestreet.com) ([38.105.200.229]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Oct 2013 15:43:18 +0100 Received: from tot-oib-smtp1.delacy.com ([172.27.22.15] helo=tot-smtp) by tot-dmz-mxout1.janestreet.com with esmtp (Exim 4.76) (envelope-from ) id 1VaRYo-0006B2-1E for caml-list@inria.fr; Sun, 27 Oct 2013 10:43:22 -0400 Received: from tot-dmz-mxgoog1.delacy.com ([172.27.224.14] helo=mxgoog2.janestreet.com) by tot-smtp with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VaRYn-000770-UA for caml-list@inria.fr; Sun, 27 Oct 2013 10:43:21 -0400 Received: from mail-ee0-f45.google.com ([74.125.83.45]) by mxgoog2.janestreet.com with esmtp (Exim 4.76) (envelope-from ) id 1VaRYn-0006DF-P2 for caml-list@inria.fr; Sun, 27 Oct 2013 10:43:21 -0400 Received: by mail-ee0-f45.google.com with SMTP id c50so3784965eek.32 for ; Sun, 27 Oct 2013 07:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d68bjY8fDsWCMtfv3mbEVMnQeR78wGJ2nrRxL7vBDOs=; b=2AdS70VZM83kY4fzetySyHrNDxaEDpgdfF6IwzfWCVqjJ3eEMwVR4sWSb5W4jqWzxL QWvTX+OM93lfVWuGbQ0vl8paxFMNCxzON8lhbSteUt+yqiR+ptMB8WTSTpR91nDgyLCt XnmVvlYToAU+yLezy1V2aCugxPf0Ep2LQujp4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=d68bjY8fDsWCMtfv3mbEVMnQeR78wGJ2nrRxL7vBDOs=; b=jOpDCYIq7R7lF8t+8YVxUSNlQ+pk0zZIi/FMT/cWPlcbiAdlBv9H2cPYpa64s0sI24 f5VzxqKPQDpccunWXUylAs2FpMTVVcbf8ldGY6ADUDOV5IGbNhXWc6zEoO+TyBij8Agj SVKlusHdWkQfoOoXxOj/XTdQgRq5feh5FQ7Wi9fAzEoQ1vwfl2/5L2U6oRj/vD3ZaHQO 4POc+xQ9vQ5EAuqSr/znzKE0oHAHiGyphyaIrmemYV5tE27EcYPWlZqG5GEwyNqTjVeP yDYuBQM9tOKTIZdYgrxcEytdHcQmDj6VbwkH1tGgxRisWTFcSRswIMQJ6Ky7T77mBwUL kLnQ== X-Gm-Message-State: ALoCoQk3L+pb2lrdSzydgwD6VXwz1ommJi4Fz9bQS9uCyBuE6NNwsb6qdOkIQUN3HB61nJr+3YsJcwqwLyD+VwqmTosCJYIsLREW3d/iLahiu8BYopz0b4hGF2EpqXgflYFCjVpeL5sO1S1CW09PMVLsTiAPW9bqEA== X-Received: by 10.14.198.197 with SMTP id v45mr17293234een.52.1382885001200; Sun, 27 Oct 2013 07:43:21 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.14.198.197 with SMTP id v45mr17293226een.52.1382885001070; Sun, 27 Oct 2013 07:43:21 -0700 (PDT) Received: by 10.223.180.138 with HTTP; Sun, 27 Oct 2013 07:43:20 -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> <66AB5484-8BFC-4A1C-ADAC-99C75716B054@mpi-sws.org> Date: Sun, 27 Oct 2013 10:43:20 -0400 Message-ID: From: Yaron Minsky To: Gabriel Scherer Cc: Andreas Rossberg , OCaML List Mailing Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Caml-list] Equality between abstract type definitions But isn't this the exact opposite of Andreas' proposal? He was proposing using '_a as a unification variable, which may very well be generalized. It is exactly this use case for '_a that seems at odds with Andreas' proposal. y On Sun, Oct 27, 2013 at 10:28 AM, Gabriel Scherer wrote: >> > Note how OCaml already uses '_a for a sort of flexible variable in its >> > output. >> Where? > > '_a is used for type variables that cannot be generalized. > > # let x = ref None;; > val x : '_a option ref = {contents = None} > # let id x = x in id id;; > - : '_a -> '_a = > > > > On Sun, Oct 27, 2013 at 1:56 PM, Yaron Minsky > wrote: >> >> On Sun, Oct 27, 2013 at 8:16 AM, Andreas Rossberg >> wrote: >> > On Oct 25, 2013, at 22:32 , Yaron Minsky wrote: >> >> Changing the semantics of this will, I think, break a _lot_ of code. >> > >> > Interesting. Do you have specific examples in mind? >> >> I know that I've seen many examples come up in my code. One common >> use is to partially specify a type. For example, if I wanted to >> ignore a return value that is a Tcp.Server.t from Async, I would >> probably write it like this: >> >> (ignore server : ('a,'b) Tcp.Server.t) >> >> without specifying the sometimes rather complicated details of those >> types. Similarly, if I were to ignore a Map, I might write >> >> (ignore map : (int,string,'a) Map.t >> >> since it's not helpful here to specify the comparator type, which is >> what goes into the third slot here. >> >> Nowadays, I would probably use an underscore in these cases rather >> than an explicit type variable, but our codebase has plenty of old >> examples of this kind of thing. If a change like the one you propose >> is changed, I presume that _ would keep its current meeting, which >> would address many use cases. >> >> Given the existence of such use-cases, I would hope that we could >> avoid making the change in a way that would non-optionally break lots >> of code. If people agree this change should be made, perhaps it >> should be done in the mode of -strict-sequence. That change was added >> as a flag, so users could take it at their own pace. >> >> >> 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. >> > >> > Maybe, but it's not my impression that this is true for most people I >> > see asking related questions here on the list or on SO. >> >> To be clear, my guess above is less than scientific. >> >> >> 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. >> > >> > Now, _that_ is something I would only expect from programmers trained on >> > SML -- ancient SML'90 to be precise. ;) >> > >> > Note how OCaml already uses '_a for a sort of flexible variable in its >> > output. >> >> Where? >> >> > /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 > >