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 EAA19116; Wed, 15 Oct 2003 04:20:10 +0200 (MET DST) 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 EAA18165 for ; Wed, 15 Oct 2003 04:20:08 +0200 (MET DST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h9F2K6103952 for ; Wed, 15 Oct 2003 04:20:06 +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-20030924/3.7W) with ESMTP id LAA25157; Wed, 15 Oct 2003 11:20:01 +0900 (JST) To: nick.name@inwind.it Cc: caml-list@inria.fr Subject: Re: [Caml-list] Is arrow programming impossible in ocaml? In-Reply-To: <200310150353.46072.nick.name@inwind.it> References: <200310141326.22497.nick.name@inwind.it> <20031015092206F.garrigue@kurims.kyoto-u.ac.jp> <200310150353.46072.nick.name@inwind.it> 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: <20031015112001U.garrigue@kurims.kyoto-u.ac.jp> Date: Wed, 15 Oct 2003 11:20:01 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 jacques:01 val:01 val:01 abstr:01 side-effect:01 decidability:01 decidability:01 soundness:01 faq:01 abstraction:01 jacques:01 ocaml:01 caml:01 sig:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: Nick Name > Here it is: > > module type ARROW = > sig > type ('a,'b) t > > val arr : ('a -> 'b) -> ('a,'b) t > val (>>>) : ('a,'b) t -> ('b,'c) t -> ('a,'c) t > val (&&&) : ('a,'b) t -> ('a,'c) t -> ('a,('b * 'c)) t > end [...] > (* now in the toplevel > > # let t = time >>> time;; > val t : ('_a, float) Var.Time.t = *) > > Well, that '_a is exactly what I wish to avoid; I see. > I had this suggestion privately (with simplified type declarations): > > # type ('a,'b) sf = Arr of ('a * float -> 'b);; > type ('a, 'b) sf = Arr of ('a * float -> 'b) > # let (>>>) f1 f2 = match f1(),f2() with (Arr f1),(Arr f2) -> Arr (fun > (a,s) -> f2 (f1(a,s),s));; > val ( >>> ) : (unit -> ('a, 'b) sf) -> (unit -> ('b, 'c) sf) -> ('a, 'c) > sf = > > # let time () = Arr (fun (_,t) -> t);; > val time : unit -> ('a, float) sf = > # let t () = time >>> time;; > val t : unit -> ('a, float) sf = > > and yet I don't know if it's satisfactory. What would be the problem? This is just about delaying the arrow construction, to make sure that no side-effect may occur. > however I realize that this > is a general problem with caml view of polymorphism, probably driven by > type-inference decidability issues; in fact I can't write a polymorphic > compose operator in general, because I will get exactly the same > problems. This has nothing to do with decidability at all! Again, this is the value restriction, which solves a problem with soundness in presence of side-effects, and this is a FAQ. And you can perfectly define a polymorphic compose operator. # let compose f g x = f (g x);; val compose : ('a -> 'b) -> ('c -> 'a) -> 'c -> 'b = The only difficulty is that to create polymorphic functions with this operator you must apply eta-expansion. # let swap (x,y) = (y,x);; val swap : 'a * 'b -> 'b * 'a = # fun p -> compose swap swap p;; - : 'a * 'b -> 'a * 'b = By the way, if you are ready to break abstraction (which in your case doesn't seem essential), you can build a t with the right polymorphic type: # let t = T(fun s -> let T a = time >>> time in a s);; val t : ('a, float) Var.Time.t = ... Not very clean, but you can replace time >>> time by any polymorphic expression. It can be made a bit simpler by using a record instead of a sum: # let t = {f=fun s -> (time >>> time).f s};; 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