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 E0F74BC6B for ; Fri, 11 Jan 2008 14:55:57 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAD8Eh0fUnw6Elmdsb2JhbACCNI1qAQEBAQcEBiIHmWY X-IronPort-AV: E=Sophos;i="4.24,271,1196636400"; d="scan'208";a="21129422" Received: from pih-relay05.plus.net ([212.159.14.132]) by mail4-smtp-sop.national.inria.fr with ESMTP; 11 Jan 2008 14:55:57 +0100 Received: from [80.229.56.224] (helo=beast.local) by pih-relay05.plus.net with esmtp (Exim) id 1JDKMU-0005Sn-EQ for caml-list@yquem.inria.fr; Fri, 11 Jan 2008 13:55:54 +0000 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Hash clash in polymorphic variants Date: Fri, 11 Jan 2008 13:48:15 +0000 User-Agent: KMail/1.9.7 References: <200801101709.14110.jon@ffconsultancy.com> <003a01c853d1$718d8730$9201a8c0@countertenor> <200801110830.29988.ober.14@osu.edu> In-Reply-To: <200801110830.29988.ober.14@osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801111348.15452.jon@ffconsultancy.com> X-Spam: no; 0.00; hash:01 variants:01 non-issue:01 show-stopper:01 hash:01 bindings:01 bindings:01 clashes:01 frog:98 polymorphic:01 wrote:01 caml-list:01 linear:02 compiling:02 imply:03 On Friday 11 January 2008 13:30:29 Kuba Ober wrote: > Are those collisions of any real importance? I mean, do they break > anything? If all they do is imply linearly searching a list of a few > elements, for the colliding entry, then it's a non-issue? It would prevent code from compiling so it would be a complete show-stopper. In this case, there is a chance that a hash clash in names that I have no control over would break my OpenGL bindings at some point in the future. A theoretical solution would be to grow the bindings and avoid clashes in identifiers included in later versions of OpenGL by adding random suffixes. Although this works in theory, in practice it places the burden of a linear search on the programmer who must then sift through the bindings to find out if the identifier they want to use happens to have had an internal clash in my bindings and, therefore, would require them to use a different identifier. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e