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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 413CC7EE25 for ; Sun, 27 Oct 2013 13:56:40 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of yminsky@janestreet.com) identity=pra; client-ip=38.105.200.229; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="yminsky@janestreet.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.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=mail3-smtp-sop.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 (mail3-smtp-sop.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=mail3-smtp-sop.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: AskBAIMMbVImacjlnGdsb2JhbABZhBO+X4EUHg4BAQEBAQYWCTyCJQEBBAFAAQE3AQ8LCw0uIhIBBQEcBhOIAQYDAplQiw2EUwEFjioGj1UHhCyYDZAbGCmEbQ X-IPAS-Result: AskBAIMMbVImacjlnGdsb2JhbABZhBO+X4EUHg4BAQEBAQYWCTyCJQEBBAFAAQE3AQ8LCw0uIhIBBQEcBhOIAQYDAplQiw2EUwEFjioGj1UHhCyYDZAbGCmEbQ X-IronPort-AV: E=Sophos;i="4.93,580,1378850400"; d="scan'208";a="32076918" Received: from mx5.janestreet.com (HELO tot-dmz-mxout1.janestreet.com) ([38.105.200.229]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Oct 2013 13:56:39 +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 1VaPtU-0001V0-GP for caml-list@inria.fr; Sun, 27 Oct 2013 08:56:36 -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 1VaPtU-0007sA-FU for caml-list@inria.fr; Sun, 27 Oct 2013 08:56:36 -0400 Received: from mail-ea0-f170.google.com ([209.85.215.170]) by mxgoog2.janestreet.com with esmtp (Exim 4.76) (envelope-from ) id 1VaPtU-0002uc-BF for caml-list@inria.fr; Sun, 27 Oct 2013 08:56:36 -0400 Received: by mail-ea0-f170.google.com with SMTP id q10so1323162eaj.1 for ; Sun, 27 Oct 2013 05:56:35 -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=jJgXF3alkYJOxoRD7M4JSqdGyo5kedLMsUo9Ph+B0ek=; b=C1zhtrrujHswUkAQu/frVveujv1MWS4KgkTCvXMBhKGyu96cEFtcckQTxupFgPcK5e BIGdV1rFe5N4z2c0aPal9eEyKdQ2oO/kL/+b63T7/WoJ+N/p4g7Rwgt6jMX8K8DUslPB rdYmVr6WnCjfVymFzPrq+ogPv2NRGGRB+kEhg= 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=jJgXF3alkYJOxoRD7M4JSqdGyo5kedLMsUo9Ph+B0ek=; b=A/IE4hz0AKkEHNgM+YU8xMI/ZlXls8mmr+Q0lllDc1ptjbCR6YEOYo240t7QMTW+ss WHz8gJq8JsgZ/riRsBo01WMpDZkZZ0k4eu70dkdvJAENUY1w7PhFTrybAjdL3YZx9FjI BVY26Tn3RwtINfJpQChPj8ThZSAKROIGiggqnrpAu7OvMlTTmVq0Dj2l++8KFdpDvNGG sDjErZANnNKO/cW3qcN8DPkXAjij+el1WveKzczCLa2huH2sGffH3mmbgGYWOw0UCMSn 4i53jFexTxMdKIhVTvqJ5ffzaCht23OCttcZ7PBkffFRO8zhbuYdmScQ5qwpipSUAroj NxTw== X-Gm-Message-State: ALoCoQnu1wZgOEirBKJ6h1VdCby7aLhVJrifNBZ2UFg+8XrQmA4YC0i8hRkePahyjIqsh7+x4d5pSSsbdu9aAOgc2L5k0uT/IAxlhRQf6+nztC1cMn7+l2aZGQXkFRRYSd/IFcTmirmWwNr+h7g6lqYcF4EPotYgKQ== X-Received: by 10.15.48.67 with SMTP id g43mr16885195eew.17.1382878595678; Sun, 27 Oct 2013 05:56:35 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.15.48.67 with SMTP id g43mr16885185eew.17.1382878595555; Sun, 27 Oct 2013 05:56:35 -0700 (PDT) Received: by 10.223.180.138 with HTTP; Sun, 27 Oct 2013 05:56:35 -0700 (PDT) In-Reply-To: <66AB5484-8BFC-4A1C-ADAC-99C75716B054@mpi-sws.org> 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 08:56:35 -0400 Message-ID: From: Yaron Minsky To: Andreas Rossberg Cc: OCaML List Mailing Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Caml-list] Equality between abstract type definitions 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 >