Re: [Caml-list] Polymorphic method question

[Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>]

From: brogoff <brogoff@speakeasy.net>

> > I'm sure you need some tricks to make it work in Java 1.5 too.
> 
> The nastiest one for Caml is a downcast, when you want to extend the data
> the new class must call the extended visitor in its visit method. But Java
> supports this, so no big deal.

Well, if you're ready to have downcasts in your code...
But then,

> > Note that, if you are ready to use a slightly less functional
> > approach, where the result is extracted from the visitor afterwards,
> > then typing is no problem.
> 
> That's probably the right way to proceed, namely to eliminate the
> problem by eliminating the polymorphic methods. Too bad, the Java
> solution is both more functional, and more "typed". One of those
> rare cases for me where I feel that the Java solution is more
> elegant than the OCaml one.

I would not say that your Java version is more "typed". It is less so
if you have downcasts!
By the way, the Scala version I mentioned uses no downcast, but cannot
accomodate polymorphic methods (at least in the mentioned paper.)
So there seems to be a tension between guaranteed type-safety and
immutability. The point is that to solve it cleanly, one has to use type
parameters in an abstract type. OCaml is able to do it, but I agree
that this is rather verbose.

[About having to write the type hierarchy by hand]
> But we have to repeat the information from the type in a later class,
> which seems redundant. Also, there's no way I know of to build object types
> from other object types, similar to the way I can combine polymorphic variant
> types.
> 
> I haven't tried to encode it yet, maybe I'll try later, but I don't
> see how it can be made to work.

Indeed. At times I wonder whether it would not be better to have a
syntax to do this with types. Or maybe not to infer parameter
constraints for class types, as they are required for extensibility.

Jacques Garrigue