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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by sympa.inria.fr (Postfix) with ESMTPS id D4D7C7ED7A for ; Tue, 4 Sep 2012 04:54:40 +0200 (CEST) Received-SPF: None (mail4-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=mail4-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 (mail4-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=mail4-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 (mail4-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=mail4-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: AiwCAPtsRVCFBoIFjGdsb2JhbAArGrtKAQEBJzuCIAEBBAEnEwkBNQIDCws0ElcGiBoFDCqmI4Q2AYYZiH8HkV9giFGNC4EUkXg X-IronPort-AV: E=Sophos;i="4.80,364,1344204000"; d="scan'208";a="154579712" Received: from rabbit.math.nagoya-u.ac.jp (HELO mailhost.math.nagoya-u.ac.jp) ([133.6.130.5]) by mail4-smtp-sop.national.inria.fr with ESMTP; 04 Sep 2012 04:54:37 +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 3135B632F; Tue, 4 Sep 2012 11:54:35 +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 F2A6340E1; Tue, 4 Sep 2012 11:54:34 +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 tet.garrigue.jp (58x158x128x157.ap58.ftth.ucom.ne.jp [58.158.128.157]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTPSA id B4C9640C3; Tue, 4 Sep 2012 11:54:34 +0900 (JST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jacques Garrigue In-Reply-To: <50451582.6080805@gmail.com> Date: Tue, 4 Sep 2012 11:54:34 +0900 Cc: caml-list@inria.fr Content-Transfer-Encoding: quoted-printable Message-Id: <949A205C-8823-45CF-89D5-6DAAA28A616C@math.nagoya-u.ac.jp> References: <50451582.6080805@gmail.com> To: Jacques-Pascal Deplaix X-Mailer: Apple Mail (2.1084) Subject: Re: [Caml-list] ocaml-4.00.0 compilation problem with first class modules and optional parameters On 2012/09/04, at 5:39, Jacques-Pascal Deplaix wrote: > Hi, >=20 > I have met some compilation problem when I tried to compile ocsimore > with ocaml-4.00.0: >=20 > Error: This expression has type > ?href_action:Wiki_syntax_types.link_action -> > ?link_action:Wiki_syntax_types.link_action -> > Wiki_syntax_types.desugar_param -> string -> string Lwt.t > but an expression was expected of type > Wiki_syntax_types.desugar_param -> string -> string Lwt.t >=20 > It's really a weird error. I tried to reproduce it in a small test-case > but I didn't succeed. >=20 > I made a patch for it in ocsimore, but it's really dirty/useless: > http://ocsigen.org/darcsweb/?r=3Docsimore;a=3Dcommitdiff;h=3D201209031522= 05-a85e5-00b22d6e2abc7c666a7700d70e3190e6aefbfd7e.gz >=20 > If someone can tell me if it's an ocaml bug or something else. >=20 > Cheers, > Jacques-Pascal Deplaix OCaml 4.00 is much more agressive in propagating expected types when typing expressions. Unfortunately, there was a conflict between this upward propag= ation, and the somehow adhoc behaviour which removes optional arguments from a function passed as argument to a function or record/variant constructor n= ot expecting optional arguments. Specifically, this is this behavior: val f : (unit -> unit) -> unit val g : ?x:int -> ?y:bool -> unit -> unit let () =3D 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/manti= s/view.php?id=3D5748 The clean fix in your case is to move the "let module" outside of the appli= cation: let module Plugin =3D (val p: WikiPlugin) in desugar_content (desugar_strin= g 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 manua= l, I suppose this qualifies as a bug. However, combining this behavior with upward propagatio= n 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 trig= gered, including "let" and "let module", but the above PR#5748 is about inlined functions, w= hich could benefit from propagation. Jacques Garrigue=