From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <garrigue@math.nagoya-u.ac.jp>
X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr
X-Spam-Level: *
X-Spam-Status: No, score=1.1 required=5.0 tests=AWL,DNS_FROM_RFC_ABUSE,
	SPF_SOFTFAIL autolearn=disabled version=3.1.3
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82])
	by yquem.inria.fr (Postfix) with ESMTP id 90077BC6C
	for <caml-list@yquem.inria.fr>; Tue,  5 Feb 2008 11:21:33 +0100 (CET)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ao8CAJfHp0eCNhAB/2dsb2JhbACsfA
X-IronPort-AV: E=Sophos;i="4.25,306,1199660400"; 
   d="scan'208";a="7612655"
Received: from kurims.kurims.kyoto-u.ac.jp ([130.54.16.1])
  by mail1-smtp-roc.national.inria.fr with ESMTP; 05 Feb 2008 11:21:32 +0100
Received: from localhost (orion [130.54.16.5])
	by kurims.kurims.kyoto-u.ac.jp (8.13.8/8.13.8) with ESMTP id m15ADhHQ000041;
	Tue, 5 Feb 2008 19:13:43 +0900 (JST)
Date: Tue, 05 Feb 2008 19:13:40 +0900 (JST)
Message-Id: <20080205.191340.243285516.garrigue@math.nagoya-u.ac.jp>
To: tab@snarc.org
Cc: daniel.buenzli@erratique.ch, caml-list@yquem.inria.fr
Subject: Re: [Caml-list] [OSR] Suggested topic - XML processing API
From: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
In-Reply-To: <20080205095137.GA3573@snarc.org>
References: <47A7EDFE.1050805@frisch.fr>
	<36788A32-5BAC-4D57-9D0A-B9A20A49536F@erratique.ch>
	<20080205095137.GA3573@snarc.org>
X-Mailer: Mew version 4.2 on Emacs 22.1 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spam: no; 0.00; 0100,:01 bunzli:01 libs:01 variants:01 variants:01 polluted:01 functorize:01 polluted:01 constructors:01 polymorphic:01 polymorphic:01 wrote:01 caml-list:01 precisely:01 variant:02 

From: tab@snarc.org (Vincent Hanquez)
> On Tue, Feb 05, 2008 at 09:36:02AM +0100, B=FCnzli Daniel wrote:
> >> - having a common spec for several libs makes more sense if they c=
an share =

> >> common types; maybe you should use polymorphic variants instead of=
 regular =

> >> ones?
> >
> > Agreed. In xmlm these variants become polymorphic in the next versi=
on.
> =

> 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" that library should never use them or at least doesn't=

> advertise them as public interface.

I have no particular opinion on this particular case (if you want to
allow chaning the library, you can also functorize your code, which
would work with normal variants too), but could you explain how
polymorphic variant namespace can get polluted?
The point of polymorphic variants is precisely that pollution does
not exist (i.e. only constructors that appear in the same type
matter). This is what makes them so nice in libraries.

Jacques Garrigue