Version française
Home     About     Download     Resources     Contact us    
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: -- (:)
From: brogoff <brogoff@s...>
Subject: Re: [Caml-list] Polymorphic method question
On Tue, 11 Jul 2006, skaller wrote:

> On Mon, 2006-07-10 at 16:25 -0700, brogoff wrote:
>
> > The restriction on polymorphism in mutually recursive class
> > definitions makes the idea unworkable. Any possibility that restriction will be
> > lifted?
>
> I don't believe there is such a restriction:

See the thread that Richard referenced, and go to Jacques Garrigue's final post.
There he writes:

    "Inside mutually recursive definitions of classes, parameters cannot be
    used polymorphically"

That's the problem, isn't it?

> the problem is
> when you introduce other types such as variants which must
> recurse with class types, there's no support for
>
> type class t1 = ..
> and t2 = [`X ..]

That's surely annoying, but it's a different problem I think.
>
> etc. The solution, using extra parameters and open
> recursion, followed by closure of the recursions,
> works but is vastly too messy to encode by hand if there
> are more than a couple of parameters needed. This really
> does need to be automated in the special case where
> you're only opening the types so you can later close them.

If you look at the faux OCaml code I provided, I believe the intent
is clear, forgiving OCaml's, ummm, suboptimal syntax. I could code
it up in Java 1.5 (maybe I should, just to make sure it works!) and
since Java doesn't do parameter inference it may all work fine.

> In general, for incremental type building, you need to retain
> the open types.. and it isn't clear if there's any way
> to make it tractable (syntactically I mean).

The code for this in Java 1.5 is quite clear, syntactically. It's a bit
tricky to get it all right, of course, but someone smarter than me already
figured it out, I just want to implement the trick in my language of
choice, which is not Java.

> Unfortunately .. the easiest kind of solution is to write
> a code generator in Python or Perl .. this kind of polymorphism
> is not exactly desirable .. ;(

No, I think you're missing the point of the "exercise" here. I'm not looking for
a code generator, but an OO approach to building extensible visitors with
precise static type checking.

-- Brian