Excerpts from daniel.buenzli's message of Tue Feb 05 11:31:22 +0100 2008:
> 
> Le 5 févr. 08 à 10:51, Vincent Hanquez a écrit :
> 
> > On Tue, Feb 05, 2008 at 09:36:02AM +0100, Bünzli Daniel wrote:
> >>> - having a common spec for several libs makes more sense if they  
> >>> can share
> >>> common types; maybe you should use polymorphic variants instead of  
> >>> regular
> >>> ones?
> >>
> >> Agreed. In xmlm these variants become polymorphic in the next  
> >> version.
> >
> > that's really a bad idea; As a user of xmlm, I hope you're going to
> > re-consider. the polymorphic variant namespace is so easily polluted  
> > by
> > random "value"
> 
> What people seem to fail to understand is that with polymorphic  
> variants if you close them and write mlis you get exactly the same  
> typechecking as with regular variants but without being tied to a  
> particular module. For example if define
> 
> type encoding = [ `ISO_8859_1 | `US_ASCII | `UTF_16 | `UTF_16BE |  
> `UTF_16LE | `UTF_8 ]
> and then ask for this type exactly in a function type, e.g.
> val encoding_to_string : encoding -> string
> then you get exactly the same typechecking as with a regular variants  
> on applications of encoding_to_string.
> Using variants allows you to have a better decoupling between say your  
> own modules that hande encodings and xmlm. As Jacques mentions this  
> actually may prevents pollution from xmlm to your own modules.

I  completely agree with this type of usage of polymorphic variants.

However  I  think  that  for  error  handling  option  and  either are simpler
solutions.  Then  going  to  polymorphic  variants  because  OCaml  don't have
"either"  in  pervasive  is sad (in fact I think that OCaml deserve a "either"
type, even more: an "Either" module).

-- 
Nicolas Pouillard aka Ertai