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 mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by sympa.inria.fr (Postfix) with ESMTPS id 87F9E7ED7A for ; Thu, 6 Sep 2012 09:31:00 +0200 (CEST) Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of jp.deplaix@gmail.com) identity=pra; client-ip=209.85.215.182; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="jp.deplaix@gmail.com"; x-sender="jp.deplaix@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail1-smtp-roc.national.inria.fr: domain of jp.deplaix@gmail.com designates 209.85.215.182 as permitted sender) identity=mailfrom; client-ip=209.85.215.182; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="jp.deplaix@gmail.com"; x-sender="jp.deplaix@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ey0-f182.google.com) identity=helo; client-ip=209.85.215.182; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="jp.deplaix@gmail.com"; x-sender="postmaster@mail-ey0-f182.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAANQSFDRVde2k2dsb2JhbAArGg66BQQBfggiAQEBAQkJCwkUBCOCIAEBAQQSAhMZARscAQEDDAYFCw0JFg8JAwIBAgEREQEFARwGDQEHAQEeh1sBAwwEByqbXQkDjCOCc4ULChknDVmIdAEFDIsFhkUDlVmBFIRLiF0+g0k8 X-IronPort-AV: E=Sophos;i="4.80,377,1344204000"; d="scan'208";a="172067203" Received: from mail-ey0-f182.google.com ([209.85.215.182]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 06 Sep 2012 09:30:59 +0200 Received: by eaak11 with SMTP id k11so592728eaa.27 for ; Thu, 06 Sep 2012 00:30:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=NS1YDyqIa5yGzbtpB7xup4KXtqxKtK8e+RCVeJ2lyh8=; b=ZycLnx5uUD/ZA7y+QFyBpCUwuxn8cKmBiSha209rUogBddpO907BA9SUxQXgjcQ9Wt Eo6lr5OtBXMmIfNeC3Y9tNhzxBEYO/2RD3CIxrj5ecU7vVJ2Ob0HUMgfnYX6JvWSoyrL G34UEdSQYVuBqe1+boeL58Dx/g0IixPJnEHwjnolGi/eBxqRzkwLTjG3JJW4kCgAvsyt 8DBUvKGhtgs0VMfW1K6t5Iuvi1DqOo9Or2v7Z3sS42kVKnT78wc8u1WsvVAueUu+b/a8 BAHIZ9cWS15V7vZLc0nEiNS9EKArjs51D+kVETBLqp/OgZBFWblNLVVFYF12w0cyGEWi 7FHA== Received: by 10.14.211.3 with SMTP id v3mr1387284eeo.43.1346916659705; Thu, 06 Sep 2012 00:30:59 -0700 (PDT) Received: from [192.168.1.10] (AMontsouris-159-1-87-48.w92-140.abo.wanadoo.fr. [92.140.14.48]) by mx.google.com with ESMTPS id h42sm3374860eem.5.2012.09.06.00.30.58 (version=SSLv3 cipher=OTHER); Thu, 06 Sep 2012 00:30:59 -0700 (PDT) Message-ID: <50485132.5010403@gmail.com> Date: Thu, 06 Sep 2012 09:30:58 +0200 From: Jacques-Pascal Deplaix User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120828 Thunderbird/15.0 MIME-Version: 1.0 To: Jacques Garrigue CC: caml-list@inria.fr References: <50451582.6080805@gmail.com> <949A205C-8823-45CF-89D5-6DAAA28A616C@math.nagoya-u.ac.jp> In-Reply-To: <949A205C-8823-45CF-89D5-6DAAA28A616C@math.nagoya-u.ac.jp> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] ocaml-4.00.0 compilation problem with first class modules and optional parameters Oh, I forgot to thank you. So, thank you for your answer. On 09/04/2012 04:54 AM, Jacques Garrigue wrote: > OCaml 4.00 is much more agressive in propagating expected types when typing > expressions. Unfortunately, there was a conflict between this upward propagation, > and the somehow adhoc behaviour which removes optional arguments from > a function passed as argument to a function or record/variant constructor not expecting > optional arguments. > > Specifically, this is this behavior: > > val f : (unit -> unit) -> unit > val g : ?x:int -> ?y:bool -> unit -> unit > > let () = f g > > This code triggers automatic discarding of the optional arguments of g, > so that the type matches the expected one. > > But for this we need to first infer the type of the argument, to see that > it doesn't match the expected one. > > I was not aware that this feature was widely used, and the behavior in 4.00.0 > is to restrict this feature to expressions where upward propagation doesn't > make sense anyway: > * identifiers > * function applications > * message sending > * record field extraction > * wrapping of "let open" around any of those > > Since "let module" is not included, this breaks the code in ocsimore... > > This is actually the same problem as reported in http://caml.inria.fr/mantis/view.php?id=5748 > > The clean fix in your case is to move the "let module" outside of the application: > > let module Plugin = (val p: WikiPlugin) in desugar_content (desugar_string Plugin.wikiparser) > > If you don't care about compatibility with 3.12, you can even write: > > | WikiPlugin (module Plugin) -> > desugar_content (desugar_string Plugin.wikiparser) > > > I'm pondering what to do about this. > Since this feature is described in the tutorial part of the reference manual, I suppose this > qualifies as a bug. However, combining this behavior with upward propagation is difficult. > > Not propagating types to function arguments seems fine, but for variant and record > constructors this is less clear-cut. > Another option is to extend the syntactic cases where the behavior is triggered, including > "let" and "let module", but the above PR#5748 is about inlined functions, which could benefit > from propagation. > > Jacques Garrigue