From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA20216 for caml-red; Tue, 6 Feb 2001 17:47:46 +0100 (MET) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id CAA26283 for ; Tue, 6 Feb 2001 02:59:00 +0100 (MET) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f161wSv26658 for ; Tue, 6 Feb 2001 02:58:29 +0100 (MET) Received: from localhost (mikan.kurims.kyoto-u.ac.jp [130.54.16.202]) by kurims.kurims.kyoto-u.ac.jp (8.9.3/3.7W) with ESMTP id KAA12461; Tue, 6 Feb 2001 10:58:07 +0900 (JST) To: mattias.waldau@abc.se, max@sbuilders.com Cc: caml-list@inria.fr Subject: RE: Typing problems when using LablGTK In-Reply-To: References: <20010205120505T.garrigue@kurims.kyoto-u.ac.jp> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010206105806K.garrigue@kurims.kyoto-u.ac.jp> Date: Tue, 06 Feb 2001 10:58:06 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) Sender: weis@pauillac.inria.fr From: "Mattias Waldau" > I also noted that typing the argument solved the problem. > > But why can't the typechecking complain if there is more than one > typing possible? The current algorithm seems to take the first > solution found and keep that. This is not a completely arbitrary solution. This is the solution that would be choosen if there were no optional arguments in the language. A better solution would require some kind of whole program analysis, to see on which function mini is applied, a bit of an overkill for a rather exceptional problem. > Couldn't it instead say, "Ambiguous typing"? Unfortunately, no. Since any function may have optional arguments, all function calls are in essence ambiguous. Still, what is ambiguous is only the typing, the semantics is defined independently of types, and guaranteed to be the same with or without type annotations. The worst thing that may happen is that your program wouldn't be accepted by the type checker. From: Maxence > let feeling = f (ctx :> string>) > > ocaml complains about the coercion of ctx : > This expression cannot be coerced to type < get_string : string -> > string >; > it has type context = < get_string : ?default:string -> string -> string > > > but is here used with type < get_string : string -> string > > > The question is : why is this coercion not allowed ? The question is : how do you compile it. Since ?default:string -> string -> string and string -> string correspond to incompatible internal representations, one would have to build a new class with the expected type, and masquerade ctx as an object of this class. This seems to be too much work and too costly for something that can be solved by a single type annotation. The only case in which such a conversion is currently done is when you pass a function with optional arguments as parameter to another function. let button = GButton.button ~packing:(vbox#pack ~from:`END) () packing has type (widget -> unit) but vbox#pack has type ?from:Gtk.Tags.pack_type -> ?expand:bool -> ?fill:bool -> ?padding:int -> widget -> unit meaning that some optional parameters are left after the partial application. Currently the compiler discards them, by eta-expanding the argument. But even this can subtly break the semantics in classic mode (not in a fundamental way, but this is a petty headache). Jacques Garrigue --------------------------------------------------------------------------- Jacques Garrigue Kyoto University garrigue at kurims.kyoto-u.ac.jp JG