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.1 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 4C12FBC6C for ; Tue, 5 Feb 2008 11:45:11 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.25,307,1199660400"; d="asc'?scan'208";a="22207082" Received: from peray.inria.fr (HELO ausone.inria.fr) ([128.93.8.98]) by mail4-relais-sop.national.inria.fr with SMTP; 05 Feb 2008 11:45:11 +0100 Received: by ausone.inria.fr (sSMTP sendmail emulation); Tue, _d Feb 2008 11:44:05 +0100 From: "Nicolas Pouillard" Cc: tab , caml-list Subject: Re: [Caml-list] [OSR] Suggested topic - XML processing API To: daniel.buenzli 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> <42E82E2A-5A21-426A-9D3F-E4BBE32F0EEC@erratique.ch> In-Reply-To: <42E82E2A-5A21-426A-9D3F-E4BBE32F0EEC@erratique.ch> Date: Tue, 05 Feb 2008 11:43:51 +0100 Message-Id: <1202207990-sup-8670@port-ext6.ensta.fr> User-Agent: Sup/git Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=-1202208245-529679-7523-801-2-="; micalg="pgp-sha1" MIME-Version: 1.0 X-Spam: no; 0.00; 0100,:01 libs:01 variants:01 variants:01 polluted:01 val:01 encodings:01 ocaml:01 ocaml:01 polymorphic:01 polymorphic:01 wrote:01 typechecking:01 typechecking:01 caml-list:01 X-Attachments: cset="UTF-8" type="application/pgp-signature" name="signature.asc" name="signature.asc" --=-1202208245-529679-7523-801-2-= Content-Type: text/plain; charset=UTF-8 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 --=-1202208245-529679-7523-801-2-= Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) iD8DBQFHqD31j+FCNw9dwLkRAix+AKCdd45P1nc2av7v10eIcAqYYyfSgwCbBQYu fVGhuRCq1juxdA3ZfGkuAWY= =dMjx -----END PGP SIGNATURE----- gpg: Invalid passphrase; please try again ... gpg: Invalid passphrase; please try again ... --=-1202208245-529679-7523-801-2-=--