From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id SAA03094 for caml-redistribution@pauillac.inria.fr; Mon, 21 Feb 2000 18:16:15 +0100 (MET) Resent-Message-Id: <200002211716.SAA03094@pauillac.inria.fr> 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 DAA08407 for ; Mon, 21 Feb 2000 03:44:54 +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 DAA18042 for ; Mon, 21 Feb 2000 03:44:51 +0100 (MET) Received: from tet.kurims.kyoto-u.ac.jp (isdnppp2.kurims.kyoto-u.ac.jp [130.54.16.103]) by kurims.kurims.kyoto-u.ac.jp (8.9.3/3.7W) with ESMTP id LAA01870; Mon, 21 Feb 2000 11:44:43 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by tet.kurims.kyoto-u.ac.jp (8.9.3/8.9.3) with ESMTP id LAA07301; Mon, 21 Feb 2000 11:44:56 +0900 (JST) (envelope-from garrigue@kurims.kyoto-u.ac.jp) To: maf@microsoft.com, caml-list@inria.fr Subject: RE: variant filtering In-Reply-To: Your message of "Sun, 20 Feb 2000 15:58:13 -0800" <783D93998201D311B0CF00805FEAA07B7E9101@RED-MSG-42> References: <783D93998201D311B0CF00805FEAA07B7E9101@RED-MSG-42> X-Mailer: Mew version 1.93 on Emacs 20.4 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000221114455F.garrigue@kurims.kyoto-u.ac.jp> Date: Mon, 21 Feb 2000 11:44:55 +0900 From: Jacques Garrigue X-Dispatcher: imput version 980905(IM100) Resent-From: weis@pauillac.inria.fr Resent-Date: Mon, 21 Feb 2000 18:16:15 +0100 Resent-To: caml-redistribution@pauillac.inria.fr From: Manuel Fahndrich > yes, I see that one has to be able to capture the row variable and it would > be part of two different types. The work-around you suggest is fine when the > number of variant cases is small and known. However, one nice thing about > polymorphic variants is their openness. Thus, enumerating all the other > cases is not really an option in many cases. There are two different problems here. One of expressiveness (all cases have to be known, clearly variants in ocaml are not as expressive as in Wallace), and another of conciseness (the need to explicitely write all cases). I think that expressiveness is not the main problem. The added expressive power is in my view too complex to be used in most programs. And in general open pattern matching on variants is not a good idea, beacuse it weakens the type checking (typos do not cause type errors). There are solutions for the conciseness problem, like allowing one to write a name of variant type instead of the complete case list: type failures = [`FailureA | `FailureB | `FailureC] let g () = match f () with `Success s -> `Success 1 | #failures as other -> other Would it be enough? Remark also that most examples that would use the extra expressiveness of explicit row variables can also be rewritten in this formalism: # let f0 = function `SuccessA x -> x | `SuccessB x -> x*2;; val f0 : [<`SuccessA int|`SuccessB int] -> int With row variables: # let protect f x = match x with `FailureA -> -1 | `FailureB -> -2 | `FailureC -> -3 | other -> f other;; val protect : (['r] -> int) -> [<`FailureA|`FailureB|`FailureC|'r] -> int # let g = protect f0;; g : [<`FailureA|`FailureB|`FailureC|`SuccessA int|`SuccessB int] -> int Without row variables: # let handler x = match x with `FailureA -> -1 | `FailureB -> -2 | `FailureC -> -3;; val handler : [<`FailureA|`FailureB|`FailureC] -> int # let g = function | #success as x -> f0 x | #failures as x -> handler x;; g : [<`FailureA|`FailureB|`FailureC|`SuccessA int|`SuccessB int] -> int As you can see, the main difference is that you have to add some glue by hand. This is less abstract than only applying a function, but the advantage is that you stay at a simpler level of reasonning. In practice I believe you do not get more verbose. Jacques --------------------------------------------------------------------------- Jacques Garrigue Kyoto University garrigue at kurims.kyoto-u.ac.jp JG