Re: [Caml-list] Polymorphic methods

[Alain Frisch <frisch@clipper.ens.fr>]

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