[Caml-list] Polymorphic variants and signatures

[Caml-list] Polymorphic variants and signatures

[brogoff]

Hi, 
    I've run into some issues with polymorphic variants that I can't find 
addressed in the manual. I'd like to define a module type which looks 
(simplified) like this

module type CELL_TYPE =
  sig
    type ('a, 'b) t

    val show_rec :
        ('a -> ('b -> string) -> string) -> ([< ('b, 'a) t ] *  'c) inst ->
            ('b -> string) -> string
    ...

  end

and obviously I can't because ('a, 'b) t is not a polymorphic variant type. 

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

-- 
-- 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

Re: [Caml-list] Polymorphic variants and signatures

[Jacques Garrigue]

From: brogoff@speakeasy.net

>     I've run into some issues with polymorphic variants that I can't find 
> addressed in the manual. I'd like to define a module type which looks 
> (simplified) like this
> 
> module type CELL_TYPE =
>   sig
>     type ('a, 'b) t
> 
>     val show_rec :
>         ('a -> ('b -> string) -> string) -> ([< ('b, 'a) t ] *  'c) inst ->
>             ('b -> string) -> string
>     ...
> 
>   end
> 
> and obviously I can't because ('a, 'b) t is not a polymorphic variant type. 
>
> 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).

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.

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

Not very helpful,

    Jacques

-------------------
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

Re: [Caml-list] Polymorphic variants and signatures

[brogoff]

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