Re: [Caml-list] Polymorphic method question

[brogoff <brogoff@speakeasy.net>]

On Tue, 11 Jul 2006, Jacques Garrigue wrote:
> From: brogoff <brogoff@speakeasy.net>
> > > 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'm not so sure about verbosity. Type syntax is pretty compact :-)

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.

> 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. Also, Java generics require that primitive
types be wrapped, a mild annoyance. That's about it. Way easier than my
attempts in OCaml, even though I don't use Java much at all. OK, to be fair,
the original paper uses some Java variant (Pizza?) so maybe that's not too
surprising. I wrote the code and it compiled, but I haven't tested it.

> I don't have the code in mind.
> I agree that the solution I posted is not too simple, but I don't
> think this is PhD level. Actually it's not much worse than the visitor
> pattern. What is hard is understanding why you have to do all this
> extra work, not using the pattern itself.

Sure, I exaggerated for affect, but I think the comparison with Java for this
problem is telling.

I'm reminded of something David MacQueen wrote in his paper "Should ML be
Object Oriented" where he says in essence that the functional core of ML
is lightweight and understandable but that OO (from the static typing POV)
is surprisingly subtle and complex.

> 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.
> This code is based on http://cristal.inria.fr/~remy/work/expr/
> It is strictly equivalent to Odersky&Zenger's Scala version.
> (Actually this kind of code is one reason we reverted to sharing of
> instance variables in 3.10)

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.

-- Brian