Re: [Caml-list] What about polymorphic union types in functors?

[Alex Baretta <alex@baretta.com>]

brogoff@speakeasy.net wrote:
> On Fri, 6 Feb 2004, Alex Baretta wrote:

> Looks like you are implementing GCaml style polymorphism by hand. Last I read,
> work on GCaml was slated to resume after 3.07. The original system looked
> quite promising, but I have no idea how it will interact with the module system,
> and all of the other non corish extensions (OO, polymorphic variants, etc)
> that make up the full language.
> 
> -- Brian

Well, I like the GCaml approach, but I think that what I need is 
actually simpler than function overloading. I actually need variant 
types, for each variant identifies a specific object, which is 
meaningful in specific context (read, set). The variant types I use are 
polymorphic because the union of two such types is meaningful in an 
enlarged context (set union).

I need the ocaml compiler to typecheck the use of variant tags to ensure 
that no tag is used in a context where it is not meaningful. The absence 
of such static typechecking would force me to throw an exception at 
runtime if a tag is used where it is not meaningful. Such typechecking 
is possible, and I actually rely heavily on it. What I need is a _union_ 
morphism between a pair of similar modules and a third module similar to 
the first two. From an algebraic stadpoint, this operator is well 
defined. However, ocaml is unable to compile such code because pattern 
matching on polymorphic variants requires all variants to be known 
statically. However, I suspect that this limitation is due to the 
implementation rather than the underlying model. If the compiler knew 
that F1.t and F2.t were polymorphic variant types, then it could 
dispatch be executing sequentially the pattern matching code for F1.t 
defined by the F1 module and the pattern matching code for F2.t defined 
in the F2 module. This can be done because at the time when F1 and F2 
are compiled all polymorphic variants are actually known. There might be 
some corner cases to be worked out, but the general principle ought to work.

Alex

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