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 211C07EE25 for ; Thu, 24 Oct 2013 03:40:48 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of garrigue@math.nagoya-u.ac.jp) identity=pra; client-ip=133.6.130.5; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="garrigue@math.nagoya-u.ac.jp"; x-sender="garrigue@math.nagoya-u.ac.jp"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of garrigue@math.nagoya-u.ac.jp) identity=mailfrom; client-ip=133.6.130.5; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="garrigue@math.nagoya-u.ac.jp"; x-sender="garrigue@math.nagoya-u.ac.jp"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mailhost.math.nagoya-u.ac.jp) identity=helo; client-ip=133.6.130.5; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="garrigue@math.nagoya-u.ac.jp"; x-sender="postmaster@mailhost.math.nagoya-u.ac.jp"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuwBAPt5aFKFBoIFnGdsb2JhbABZwmuBQg4BAQEBAQgUCTyCJQEBBAEnHAE1AgMLC0YhNgYTh3QDCQWnfoRZAoR2DVeJDQeMYIEvgQwzB4MfgQuJQIxhgWuMUIhqLYEs X-IPAS-Result: AuwBAPt5aFKFBoIFnGdsb2JhbABZwmuBQg4BAQEBAQgUCTyCJQEBBAEnHAE1AgMLC0YhNgYTh3QDCQWnfoRZAoR2DVeJDQeMYIEvgQwzB4MfgQuJQIxhgWuMUIhqLYEs X-IronPort-AV: E=Sophos;i="4.93,558,1378850400"; d="scan'208";a="31615982" Received: from rabbit.math.nagoya-u.ac.jp (HELO mailhost.math.nagoya-u.ac.jp) ([133.6.130.5]) by mail3-smtp-sop.national.inria.fr with ESMTP; 24 Oct 2013 03:40:45 +0200 Received: from mailhost.math.nagoya-u.ac.jp (localhost [127.0.0.1]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTP id 2DEEE63A4; Thu, 24 Oct 2013 10:40:42 +0900 (JST) Received: from mailhost.math.nagoya-u.ac.jp (localhost [127.0.0.1]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTP id 0179040E0; Thu, 24 Oct 2013 10:40:42 +0900 (JST) DomainKey-Signature: h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=; c=nofws; d=math.nagoya-u.ac.jp; q=; s=alpha Received: from garrigue-mini.math.nagoya-u.ac.jp (garrigue-mini.math.nagoya-u.ac.jp [172.16.30.37]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTP id EA5BB40C4; Thu, 24 Oct 2013 10:40:41 +0900 (JST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=iso-8859-1 From: Jacques Garrigue In-Reply-To: Date: Thu, 24 Oct 2013 10:40:41 +0900 Cc: Caml List Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Bob Zhang X-Mailer: Apple Mail (2.1510) Subject: Re: [Caml-list] Robust left to right flow for record disambiguation On 2013/10/24, at 5:52, Bob Zhang wrote: > Record disambiguation is a practical feature, it helps a lot in > writing open-free code. > In practice, I found it is a bit limited, below is two scenarios > that the compiler can not infer in a correct way, will this be > improved in the future by any chance? > From the user's point of view, annotating the toplevel is quite > acceptable, maybe the typechecker could take the type-annotation as a > higher priority. > --- > 1. > let f (ls:t) =3D > ls |> List.map (fun x -> x.loc) (* cannot inferred x.loc*) > 2. > type t =3D {loc:string} > type v =3D {loc:string; x:int} > type u =3D [`Key of t] > let f (u:t) =3D > match u with > | `Key {loc} -> loc (* does not compile *) Case 1 would require a new specification of how type propagation works. In particular, propagating from an argument to another argument. For this reason, the probability that it gets done is low. (I know that F# handles this case in a special way, but do we want to intro= duce a special case just for |> ?) Case 2 seems more reasonable (after replacing (u:t) by (u:u)). In particular, let f (u:u) =3D match u with `Key loc -> loc.loc already works, so it seems strange that the pattern-matching version doesn'= t. Jacques=