From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.0 required=5.0 tests=AWL,SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id A1C80BC6C for ; Tue, 5 Feb 2008 11:31:28 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAACvKp0fRVZKyk2dsb2JhbACQKgEBAQEHBAQLCBaWLIVx X-IronPort-AV: E=Sophos;i="4.25,306,1199660400"; d="scan'208";a="22206043" Received: from wa-out-1112.google.com ([209.85.146.178]) by mail4-smtp-sop.national.inria.fr with ESMTP; 05 Feb 2008 11:31:25 +0100 Received: by wa-out-1112.google.com with SMTP id k17so2941578waf.3 for ; Tue, 05 Feb 2008 02:31:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:sender; bh=UWtYGWTp5FYmp6gp32yqLsarNENqSvcFIgfipbsDZ0I=; b=TzS71l26w2/50oOAEF4AkKfbG3A+H3FPV4GDPI7xhN9t2Mq9rJr3K+kl8vPXl6nDUlOMAPHvcRunyIrJnuOd1orHFRLM152Z4j4f8l28/kOH1G7y6Acn/Xr7gvDg4nmdrf2qYaWPf1UvnzzCmOUV0wPMPT3w5j/d0zGZUHahchc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:sender; b=bcUqzt/GnwID2i8KDiuzMMYy6JnJDibVAxh8urjpAFxkCAxtOZ0dEb9jbtzDgmrctgAduRv4SWH2aRI/d28jso+IcAtvmYh+Vhaqh4DWV+mUaQ+x12+q5NsS142euiqfyGuf1CI9n2jXXUoscfXlkEynoA+nxWvK2brvf4KiZ9s= Received: by 10.114.198.1 with SMTP id v1mr5972991waf.89.1202207482492; Tue, 05 Feb 2008 02:31:22 -0800 (PST) Received: from ?192.168.1.58? ( [85.1.105.53]) by mx.google.com with ESMTPS id h7sm199243nfh.24.2008.02.05.02.31.20 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Feb 2008 02:31:21 -0800 (PST) Cc: caml-list caml-list Message-Id: <42E82E2A-5A21-426A-9D3F-E4BBE32F0EEC@erratique.ch> From: =?ISO-8859-1?Q?B=FCnzli_Daniel?= To: Vincent Hanquez In-Reply-To: <20080205095137.GA3573@snarc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [Caml-list] [OSR] Suggested topic - XML processing API Date: Tue, 5 Feb 2008 11:31:22 +0100 References: <52FAAA41-5B70-4F87-9F83-B8A96EA48D34@erratique.ch> <200801301035.31447.jon@ffconsultancy.com> <47A7EDFE.1050805@frisch.fr> <36788A32-5BAC-4D57-9D0A-B9A20A49536F@erratique.ch> <20080205095137.GA3573@snarc.org> X-Mailer: Apple Mail (2.915) Sender: =?ISO-8859-1?Q?Daniel=20B=FCnzli?= X-Spam: no; 0.00; bunzli:01 buenzli:01 0100,:01 bunzli:01 libs:01 variants:01 variants:01 polluted:01 val:01 encodings:01 polymorphic:01 polymorphic:01 wrote:01 typechecking:01 typechecking:01 Le 5 f=E9vr. 08 =E0 10:51, Vincent Hanquez a =E9crit : > 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 =20 >>> can share >>> common types; maybe you should use polymorphic variants instead of =20= >>> regular >>> ones? >> >> Agreed. In xmlm these variants become polymorphic in the next =20 >> 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 =20= > by > random "value" What people seem to fail to understand is that with polymorphic =20 variants if you close them and write mlis you get exactly the same =20 typechecking as with regular variants but without being tied to a =20 particular module. For example if define type encoding =3D [ `ISO_8859_1 | `US_ASCII | `UTF_16 | `UTF_16BE | =20 `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 =20= on applications of encoding_to_string. Using variants allows you to have a better decoupling between say your =20= own modules that hande encodings and xmlm. As Jacques mentions this =20 actually may prevents pollution from xmlm to your own modules. Best, Daniel