English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Polymorphic method question
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2006-07-11 (05:22)
From: brogoff <brogoff@s...>
Subject: Re: [Caml-list] Polymorphic method question
On Tue, 11 Jul 2006, Jacques Garrigue wrote:

> From: brogoff <brogoff@speakeasy.net>
> Because bar is not yet completely defined when you use it in foobar.
> This is all related with parameter constraint inference: we don't know
> yet wether bar's parameter is really polymorphic or is constraint (e.g.
> 'a = 'b * 'c).
> Note that the problem does not occur with direct type definitions, as
> constraint inference is not done in that case (this is one of the
> reasons you cannot combine type and class definitions.)
> # type 'a bar = < get: 'a > and foobar = < f : 'a. 'a bar -> 'a >;;
> type 'a bar = < get : 'a >
> and foobar = < f : 'a. 'a bar -> 'a >
> The only way to solve this problem would be to remove parameter
> constraint inference from classes. It would certainly break some
> programs, so this seems difficult.

That's too bad, as it seems the class based OO version of the extensible
visitor is fairly straightforward in OCaml except for this counterintuitive
gotcha. What would have to be done to fix the broken programs? It may be
worth considering.

> By the way, if you're ready to define your types first, then you
> can do this properly.

In the more realistic example I sent along after, you'll see that this
solution is not really pleasing. You'd need to create a parallel type
hierarchy to match your class hierarchy, which is too verbose. All this
because we must have inference, which is supposed to make things less
verbose. Ironic, isn't it? ;-)

I have seen the new private rows stuff, which is very nice, but all of these
solutions IMO are way too complex to be considered satisfactory. I'll see if
the Java 1.5 approach actually works (I used some Pizza code to do the OCaml
implementation) because that was quite straightforward. I'd prefer approaches
that I can explain with a little hand waving. I think type theorists often
forget that there are a few programmers still who don't have PhDs in type
theory and will look at such solutions and conclude that OCaml is not for
them ;-).

-- Brian