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 PAA26634 for caml-redistribution; Wed, 24 Mar 1999 15:31:39 +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 CAA18212 for ; Wed, 24 Mar 1999 02:40:12 +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.8.7/8.8.7) with ESMTP id CAA29905 for ; Wed, 24 Mar 1999 02:40:09 +0100 (MET) Received: from localhost (safran.kurims.kyoto-u.ac.jp [130.54.16.91]) by kurims.kurims.kyoto-u.ac.jp (8.9.1a/3.7W) with ESMTP id KAA12951; Wed, 24 Mar 1999 10:39:40 +0900 (JST) To: whitley@cse.buffalo.edu Cc: caml-list@inria.fr Subject: Re: OLabl optional arguments and higher order functions In-Reply-To: Your message of "Thu, 18 Mar 1999 01:35:40 -0500 (EST)" <14064.39685.480989.489383@hadar.cse.Buffalo.EDU> References: <14064.39685.480989.489383@hadar.cse.Buffalo.EDU> X-Mailer: Mew version 1.93 on Emacs 20.3 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990324103824S.garrigue@kurims.kyoto-u.ac.jp> Date: Wed, 24 Mar 1999 10:38:24 +0900 From: Jacques GARRIGUE X-Dispatcher: imput version 980905(IM100) Content-Transfer-Encoding: 7bit Sender: weis *** This is an olabl specific message *** From: John Whitley > Consider the following example, from OLabl 2.02: > > # let ack ?:x [< 0 >] :y = x * y;; > val ack : ?x:int -> y:int -> int = > # let hack funarg = funarg x:4 y:5;; > val hack : (x:int -> y:int -> 'a) -> 'a = > # hack ack;; > Characters 5-8: > This expression has type ?x:int -> y:int -> int but is here used with > type > x:int -> y:int -> 'a > > This seems like a bug. Intuitively, labels x: and ?x: should unify. > If not, I would appreciate a brief explanation as to why not... Here is the explanation: Optional arguments are essentially a first-order feature. If a function is known to have optional arguments, and is applied to less arguments than needed, then the system automatically fills in the gaps and corrects the type. However, if we do not know the type of the function, we cannot do this processing. This is why in hack funarg's x argument is inferred not to be optional. Internally, x: and ?x: are represented differently (?x: uses an option type), so we cannot unify them safely, which explains the type error. Once you have read that, you realize that this is meaningless to pass a function with unnapplied optional arguments to a functional: you would not be able to use it anyway. Olabl avoids the problem by automatically discarding all optional arguments when a function is passed as parameter to a functional (the error message is a bit misleading about that). The following definition works fine: # let hack f = f y:5;; val hack : (y:int -> 'a) -> 'a = # hack ack;; - : int = 0 > Forcibly replacing the optional argument with the same label via > fun works just fine: > # hack (fun :x -> ack :x);; > - : int = 20 This is the only reasonable solution I see. Regards, Jacques --------------------------------------------------------------------------- Jacques Garrigue Kyoto University garrigue at kurims.kyoto-u.ac.jp JG