Re: [Caml-list] Polymorphic variants and signatures

[brogoff@speakeasy.net]

On Mon, 16 Jun 2003, Jacques Garrigue wrote:
[...snip...]
> > Is there some way I can write such a module type, and, after having
> > written it, use it in a functor as follows, 
> > 
> > module Make (Cell : CELL_TYPE) = 
> >   struct 
> >     type ('a, 'b) t = [`Newtag of 'b list | ('a, 'b) Cell.t]
> > 
> >     (* and some dispatch on `Newtag and #Cell.t *)
> >   end
> 
> This is just plain impossible. In order to dispatch on a variant
> type, you must explicitely know all its cases. If Cell.t is
> abstract,then the pattern #Cell.t is not defined. Even allowing just
> your type definition would make then implementation unsound (all
> complete variant types must known).

I thought this was probably the case, since, as you say below, polymorphic 
variants (and objects) don't mix well with a functorized style of programming 
and they don't really support type abstraction. 

It's true that I'm trying to have my cake (type abstraction) and eat it 
(dispatch on the abstract tags) too.

> This is just the same thing as with objects: you cannot build a functor
> to create a class inheriting from a class given in parameter, as long
> as you don't give an explicit class type for the parameter, indicating
> at least all the public methods.
> 
> Polymorphic variant don't mix well with functors: they allow
> incremental progamming, but not type abstraction. Do you really need a
> functor here? Actually, both variants and objects alleviate a great
> part of the need for functors.

I suppose I can get by without functors. The reason I was considering 
functorizing the code is that I was trying to abstract the incremental 
building of a variant type (you're familiar with the example, where I 
start with leaves, rows, and columns in a basic type, then add matrices and 
virtual grids and ...) such that I could more easily alternate the order 
of the successive additions. Right now each addition requires the last thing to 
be added to textually refer to the previous thing. I was hoping to get beyond 
that. 

I hope that last paragraph made sense. I'm still looking for a better approach 
to this. Hopefully you'll write something up in your next paper on the topic. 

> Of course, if you make t concrete in CELL_TYPE, there is no problem.

Right, but in that case the functor approach is no longer that useful. 

> Not very helpful,

Helpful enough. This confirmed some of my suspicions. Thanks!

-- Brian


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners