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 UAA05723; Sun, 24 Feb 2002 20:50:35 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id UAA05852 for ; Sun, 24 Feb 2002 20:50:34 +0100 (MET) Received: from mail.cs.net.pl (cyber.cs.net.pl [62.233.142.98]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g1OJoX119822 for ; Sun, 24 Feb 2002 20:50:33 +0100 (MET) Received: by mail.cs.net.pl (Postfix, from userid 510) id D2500847; Sun, 24 Feb 2002 20:50:28 +0100 (CET) Date: Sun, 24 Feb 2002 20:50:28 +0100 From: Tomasz Zielonka To: CAML list Subject: Re: [Caml-list] Narrowing coercions for functions with optional parameters Message-ID: <20020224195028.GA11234@cs.net.pl> References: <20020224140125.GA26745@cs.net.pl> <20020224183323.GB4757@cs.unibo.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020224183323.GB4757@cs.unibo.it> User-Agent: Mutt/1.3.27i Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sun, Feb 24, 2002 at 07:33:23PM +0100, Stefano Zacchiroli wrote: > On Sun, Feb 24, 2002 at 03:01:25PM +0100, Tomasz Zielonka wrote: > > # let coerce f x = f x > > val coerce : ('a -> 'b) -> 'a -> 'b = > > > > # coerce g ;; > > - : int -> int = > > With such a call you haven't change the original "g" function so the > coersion of "g" to "int -> int" doesn't work because it was applied to > the old "g" function. Yes, I want it that way. Maybe I wasn't clear enough. Let's try again. My original question was: Is is possible to implement narrowing coercions for functions with optional parameters. Such coercion would erase optional parameters not found in target type. It is similar to coercing one class to another, when methods not found in the target class are hidden/"erased". Lets say you have several functions of the same type - some request handlers which take request as argument and return reply. type request and reply type handler = request -> reply You could place them in a list, hash table or some other structure, from which they are taken to handle typical requests. Imagine that in some situation you would like to call one handler from another passing some additional parameters. Of course the former handler will have different type (optional labeled parameters). Now you can't put it in the list with others (unless you wrap it in other function with appropriate type). Then it would be nice if you could just do (g :> handler), and get the optional parameters erased. When I was preparing an example, it came to me that such coercions are sometimes performed automatically: We have: val coerce : ('a -> 'b) -> 'a -> 'b = val g : ?add:int -> int -> int = When 'coerce' is applied to 'g' the type of 'g' must be unified with type of 'coerce's argument, that is: ?add:int -> int -> int is unified with 'a -> 'b The only way to do it is to _erase_ optional argument ?add and then substitute int for both 'a and 'b. So here 'g' was used with type int -> int, optional argument ?add being automatically erased. Here the coercion was implicit. It DOES WORK in Ocaml 3.04 I would like that it was also possible to explicitly coerce 'g' to type int -> int like in: (g : int -> int) or rather (g :> int -> int) But this DOESN'T WORK. So now the question is: Why implicit coercions are performed and explicit coercions are not allowed? > Try this (after executing your examples of course): > > # let g = coerce g;; > val g : int -> int = > # (g : int -> int) ;; > - : int -> int = Then the second phrase is only type assertion (or something) not coercion. Not an interesting coercion. > Hope this helps. > Cheers. Hope I was clear enough this time. tom -- .-. Tomasz Zielonka CYBER SERVICE oo| programista http://www.cs.net.pl /`'\ zielony@cs.net.pl (\_;/) tel: [48] (22) 723-06-79 | tel/fax: [48] (22) 723-01-75 ------------------- 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