Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
To: brogoff@speakeasy.net
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Polymorphic variants and signatures
Date: Mon, 16 Jun 2003 10:11:12 +0900	[thread overview]
Message-ID: <20030616101112O.garrigue@kurims.kyoto-u.ac.jp> (raw)
In-Reply-To: <Pine.LNX.4.44.0306142235560.29773-100000@grace.speakeasy.net>

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


  reply	other threads:[~2003-06-16  1:11 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-15  6:01 brogoff
2003-06-16  1:11 ` Jacques Garrigue [this message]
2003-06-16  5:21   ` brogoff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030616101112O.garrigue@kurims.kyoto-u.ac.jp \
    --to=garrigue@kurims.kyoto-u.ac.jp \
    --cc=brogoff@speakeasy.net \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox