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=0.0 required=5.0 tests=AWL 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 0597EBC6C for ; Tue, 5 Feb 2008 12:21:31 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAOXVp0fUVZgL/2dsb2JhbACseg X-IronPort-AV: E=Sophos;i="4.25,307,1199660400"; d="scan'208";a="22209433" Received: from hades.snarc.org ([212.85.152.11]) by mail4-smtp-sop.national.inria.fr with ESMTP; 05 Feb 2008 12:21:18 +0100 Received: by hades.snarc.org (Postfix, from userid 1000) id 60F7A1B482; Tue, 5 Feb 2008 12:21:16 +0100 (CET) Date: Tue, 5 Feb 2008 12:21:16 +0100 To: =?iso-8859-1?Q?B=FCnzli?= Daniel Cc: caml-list caml-list Subject: Re: [Caml-list] [OSR] Suggested topic - XML processing API Message-ID: <20080205112116.GC4712@snarc.org> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <42E82E2A-5A21-426A-9D3F-E4BBE32F0EEC@erratique.ch> X-Warning: Email may contain unsmilyfied humor and/or satire. User-Agent: Mutt/1.5.16 (2007-06-11) From: tab@snarc.org (Vincent Hanquez) X-Spam: no; 0.00; 0100,:01 bunzli:01 polluted:01 variants:01 variants:01 val:01 encodings:01 functor:01 polluting:01 ocaml:01 8850:98 polymorphic:01 polymorphic:01 wrote:01 typechecking:01 On Tue, Feb 05, 2008 at 11:31:22AM +0100, Bünzli Daniel wrote: >> 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 you might have the same typechecking, but consider my example in the other thread. If I type `ISO_8850_1 somewhere by mistake, the error reporting is going to be extremely crappy. > 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. That's true you could do that if you want to provide interface, but you got functor to achieve the same result, without using polymorphic variant and without polluting your own modules, with still the same strong type thing that people using ocaml are used to. -- Vincent Hanquez