From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p7I8wZvm009203 for ; Thu, 18 Aug 2011 10:58:35 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AugBAInTTE7RVaC2kGdsb2JhbABBmV2PCggUAQEBAQkJDQcUBCGBQAEBAQECARICLAEbHQEDAQsGBQQHOyIBEQEFARwZIodOm0wKjDeCVYUGO4htAgMGhkIEkxOMWTyDYg X-IronPort-AV: E=Sophos;i="4.68,244,1312149600"; d="scan'208";a="105738483" Received: from mail-gy0-f182.google.com ([209.85.160.182]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 18 Aug 2011 10:58:29 +0200 Received: by gyd10 with SMTP id 10so1889750gyd.27 for ; Thu, 18 Aug 2011 01:58:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=mMUuomVkeICPFpDiAjbdabBWzLOd4FTvkNWr1SRK8Ts=; b=NtSwjEBPQFidvN9iM82Wy8thH5MyzwM+vPBycdeLFY/f+obQoIIIUVmhw5v9s7oApe f3YSY9ZSVnzbI0CihMc4HB4Tms1st1OhH+TAnhoR4vjjgaKA6aKNeC2vF3wETTvptFma TnFHYqyUyZqu42zXu1FPc2WeGbW0ekdDuD2Og= Received: by 10.101.87.1 with SMTP id p1mr489844anl.35.1313657908117; Thu, 18 Aug 2011 01:58:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.67.16 with HTTP; Thu, 18 Aug 2011 01:58:08 -0700 (PDT) In-Reply-To: <20110818080254.GA10854@ccellier.rd.securactive.lan> References: <4E4CC071.1060900@inria.fr> <20110818080254.GA10854@ccellier.rd.securactive.lan> From: Gabriel Scherer Date: Thu, 18 Aug 2011 10:58:08 +0200 Message-ID: To: rixed@happyleptic.org Cc: caml-list Content-Type: multipart/alternative; boundary=001636eee1faf8412204aac3d0cc Subject: Re: [Caml-list] [Ann] Zarith --001636eee1faf8412204aac3d0cc Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 18, 2011 at 10:02 AM, wrote: > Is there anything special in 3.12.1 to help library authors define > specialized comparison operators ? > Yes, from the 3.12.1 changelog: > - Added new operation 'compare_ext' to custom blocks, called when > comparing a custom block value with an unboxed integer. > The following fix is also possibly relevant: > - Hardened generic comparison in the case where two custom blocks > are compared and have different sets of custom operations. I believe the comparison hardening was made desirable by the expected use of first-class modules to encode existential datatypes: with existential datatypes you may try to use the polymorphic comparison operators on two values of the same (existential) datatype having different internal representations. The problem didn't happen with the previous encoding of existential types using first-class polymorphism, as it implies packing the value inside closures, so the polymorphic comparison operators were not usable. --001636eee1faf8412204aac3d0cc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 18, 2011 at 10:02 AM, <rixed@happyleptic.org= > wrote:
Is there anything special in 3.12.1 to help library authors define
specialized comparison operators ?
=A0
Yes, from th= e 3.12.1 changelog:
- Added new operation 'compare_ext' to custom blocks, called when =A0comparing a custom block value with an unboxed integer.

The=A0 following fix is also possi= bly relevant:
- Hardened generic comparison in the case where two custom blocks
=A0are compared and have different sets of custom operations.
=

I believe the comparison hardening was made desirable by the expec= ted use of first-class modules to encode existential datatypes: with existe= ntial datatypes you may try to use the polymorphic comparison operators on = two values of the same (existential) datatype having different internal rep= resentations. The problem didn't happen with the previous encoding of e= xistential types using first-class polymorphism, as it implies packing the = value inside closures, so the polymorphic comparison operators were not us= able.
--001636eee1faf8412204aac3d0cc--