From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id CAA08251; Sat, 6 Sep 2003 02:53:29 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 CAA14986 for ; Sat, 6 Sep 2003 02:53:28 +0200 (MET DST) 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.11.1) with ESMTP id h860rQT11957 for ; Sat, 6 Sep 2003 02:53:27 +0200 (MET DST) Received: from localhost (suiren.kurims.kyoto-u.ac.jp [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.9.3p2/3.7W) with ESMTP id JAA24336; Sat, 6 Sep 2003 09:53:21 +0900 (JST) To: Alain.Frisch@ens.fr Cc: caml-list@inria.fr Subject: Re: [Caml-list] Type inference + optional parameters In-Reply-To: References: <20030903110813O.garrigue@kurims.kyoto-u.ac.jp> X-Mailer: Mew version 1.94.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20030906095334H.garrigue@kurims.kyoto-u.ac.jp> Date: Sat, 06 Sep 2003 09:53:34 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 inference:01 jacques:01 alain:01 frisch:01 jacques:01 bauer:01 bauer:01 ocamls:01 inference:01 type-safe:01 multimatch:01 unification:01 wolfram:01 kahl:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: Alain.Frisch@ens.fr > On Wed, 3 Sep 2003, Jacques Garrigue wrote: > > From: Christoph Bauer > > > > > ocamls type inference uses information of optionl arguments. This > > > results in a strange behaviour. > > > > Brian Rogoff already answered this one. Do you seriously expect a > > type-safe compiler to simply ignore the type of the default value :-) > > I guess the original question is not that naive. It would be possible to > have a type system with an extension like your multimatch, to make the > type of the result of a function depend on the presence/absence of > optional argument. > > With a crazy syntax to express conditional unification constraints, you > could write for instance: > > do_with_opt_conv: ?conv:('a -> 'b orelse 'b = 'a) -> 'a -> 'b > > meaning that in the absence of the optional argument, the result type > must be unified with the argument type (there are more constraints > when the optional argument is not provided). > > Does it make sense ? It makes sense, and is just a direct consequence of the Default module I was describing in my mail. I've already considered it 4 years ago, after a comment for Wolfram Kahl. However, if you let this behaviour be active with all default parameters, you end up with overly general types; usually you expect the concrete argument to be of the same type as the default. Moreover, there may be hidden pitfalls: type incompatibilities you only detect later, when several optional parameters are omitted simultaneously. All in all, I think that this feature is just on the borderline of practical typing: possible, but the typing is too complex for casual use, and may result in confusing type errors. In some cases being explicit simplifies lots of things... Jacques Garrigue ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners