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=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id DC15DBC6B for ; Sun, 10 Feb 2008 17:51:39 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAAa6rkfR4q8inmdsb2JhbACBWY5hAQEBAQEGBAYJAgYIEJU7 X-IronPort-AV: E=Sophos;i="4.25,330,1199660400"; d="asc'?scan'208";a="9003480" Received: from tomts13.bellnexxia.net (HELO tomts13-srv.bellnexxia.net) ([209.226.175.34]) by mail3-smtp-sop.national.inria.fr with ESMTP; 10 Feb 2008 17:51:39 +0100 Received: from toip5.srvr.bell.ca ([209.226.175.88]) by tomts13-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20080210165137.IAQH22392.tomts13-srv.bellnexxia.net@toip5.srvr.bell.ca> for ; Sun, 10 Feb 2008 11:51:37 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAEO6rkdBXxW6/2dsb2JhbACBWaRa Received: from bas1-kitchener06-1096750522.dsl.bell.ca (HELO neptune.mattcox.ca) ([65.95.21.186]) by toip5.srvr.bell.ca with ESMTP; 10 Feb 2008 11:52:05 -0500 Received: from matt by neptune.mattcox.ca with local (Exim 4.68) (envelope-from ) id 1JOFOu-0006Y0-LW for caml-list@yquem.inria.fr; Sun, 10 Feb 2008 11:51:32 -0500 Date: Sun, 10 Feb 2008 11:51:32 -0500 From: Matthew William Cox To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] [OSR] Exceptionless error management, take 2 Message-ID: <20080210165132.GA23798@neptune.mattcox.ca> References: <1202396482.6084.5.camel@Blefuscu> <20080208.001729.233402575.garrigue@math.nagoya-u.ac.jp> <20080208095333.GA582@snarc.org> <200802081907.58290.jon@ffconsultancy.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline In-Reply-To: <200802081907.58290.jon@ffconsultancy.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Spam: no; 0.00; variants:01 constructors:01 programmer's:01 unpolluted:01 compiler:01 foo:01 foo:01 cheers:01 polymorphic:01 wrote:01 overlap:01 parsing:01 integer:01 caml-list:01 functions:01 X-Attachments: type="application/pgp-signature" name="signature.asc" --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 08, 2008 at 07:07:58PM +0000, Jon Harrop wrote: > As Jacques said, polymorphic variants don't define anything, i.e. don't b= ind=20 > identifiers to type constructors. So they can't pollute anything. The "fl= at=20 > namespace" you refer to doesn't exist. They do exist in a flat namespace, just not a namespace that resides in the compiler's abstractions. They do live in the programmer's *mind*, and there it is crucial to keep things unpolluted. The compiler will always (modulo bugs) keep things perfectly straight and not confuse itself. Humans will. (Programming) languages are designed to convey machine instructions meaningfully to humans, so befuddling the poor human is working against what the language is there do. As has been pointed out, `Error 1 could have totally different semantic meanings in a module for parsing XML, and a module for POSIX functions. No namespace has been `polluted' since `Error is still available for me to use. That's not the pollution I'm concerned about. The pollution I care about is the semantic overlap that *I* have to deal with. > This is the same as strings. You would not discourage the use of "foo" in= =20 > programs because it "pollutes the flat namespace of strings" for the same= =20 > reason. Sure, values can't pollute anything, just like using a lot of 5's doesn't pollute the integer namespace. On the other hand, raising Failure "foo" in 50 different functions for as many different reasons would be semantic pollution. Cheers, Matthew --Kj7319i9nmIyA2yE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHryuULzoc++7UJR8RAuwNAKCZbvvc850EfMfPPSKoTzh5KjEcmwCfRjth IMz/KoFs0d9cabEmofne0Rg= =QiyF -----END PGP SIGNATURE----- --Kj7319i9nmIyA2yE--