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 KAA23155; Tue, 20 Nov 2001 10:33:32 +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 KAA23380 for ; Tue, 20 Nov 2001 10:33:31 +0100 (MET) Received: from nef.ens.fr (nef.ens.fr [129.199.96.32]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id fAK9XUb24226 for ; Tue, 20 Nov 2001 10:33:30 +0100 (MET) Received: from clipper.ens.fr (clipper-gw.ens.fr [129.199.1.22]) by nef.ens.fr (8.10.1/1.01.28121999) with ESMTP id fAK9XTU94622 ; Tue, 20 Nov 2001 10:33:29 +0100 (CET) Received: from localhost (frisch@localhost) by clipper.ens.fr (8.9.2/jb-1.1) id KAA18636 ; Tue, 20 Nov 2001 10:33:28 +0100 (MET) Date: Tue, 20 Nov 2001 10:33:28 +0100 (MET) From: Alain Frisch To: Jacques Garrigue cc: Subject: Re: [Caml-list] Polymorphic methods In-Reply-To: <20011120092918S.garrigue@kurims.kyoto-u.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Good news that polymorphic methods are still considered ! On Tue, 20 Nov 2001, Jacques Garrigue wrote: > What would you need them for? One reason I was not so eager to start > working on them is that they do not solve all problems of > polymorphism. For instance, you cannot define a map method, even with > polymorphic methods. Oh, I never used OLabl and was not aware of this kind of restriction; why is a map method impossible ? I can't find the argument in your _Extending ML with semi-explicit higher order polymorphism_ I currently need polymorphic method for the Bedouin project. We use polymorphic variants to statically enforce DTD constraints on produced documents. For instance, we have: val html_ : ?lang:string -> ?dir:[ `Ltr | `Rtl ] -> ('a,[< `Head ]) t -> ('a,[< `Body ]) t -> ('a,[> `Html]) t Now I want to define GUI-like widgets, such as HTML forms, or INPUT interactors. For instance, the form widget should have a method html, with polymorphic type: [< `P | `H1 | `H2 | `H3 | `H4 | `H5 | `H6 | `Ul | `Ol | `Dir | `Menu | `Pre | `Dl | `Div | `Center | `Noscript | `Noframes | `Blockquote | `Isindex | `Hr | `Table | `Fieldset | `Address | `Pcdata | `Tt | `I | `B | `U | `S | `Strike | `Big | `Small | `Em | `Strong | `Dfn | `Code | `Samp | `Kbd | `Var | `Cite | `Abbr | `Acronym | `A | `Img | `Applet | `Object | `Font | `Basefont | `Br | `Script | `Map | `Q | `Sub | `Sup | `Span | `Bdo | `Iframe | `Input | `Select | `Textarea | `Label | `Button > `Input] html list -> [> `Form] html (btw, in the type to left of the arrow, isn't the " > `Input " redundant ?) Would such a method be accepted ? As the html methods are normally (but not necessarily) used only once to display widgets, it is possible to parametrize widget classes with the type of their html method (this produces constraints on the type parameter, such as : constraint 'a = [ < `P ... ]), but then, as there is a hierarchy of objects (a widget belongs to a form belongs to a dialog), the type parameters accumulate, and the interface of the widget library becomes ugly. > > Did OLabl raise some practical problems with polymorphic methods ? > > There was a problem of compilation speed. I have now a few ideas of > how to improve it, but this may still mean that the change would only > be provided as a patch. Does the compilation scheme impact on the whole language, even for programs not using polymorphic methods ? > Another problem is that such methods cannot be inferred. As a result > you can have strange type errors, because you used a method before > knowing its actual type. In OLabl there was a warning every time you > used a method whose type was unkwown, but I have been told it was not > very Caml-like. Well, with the class parametrization trick, it is also necessary to give a type annotations (just 'a is ok, and let the type system infer constraints on 'a). Thank you ! Alain ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr