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.4 required=5.0 tests=AWL,HTML_MESSAGE,SPF_SOFTFAIL 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 770A9BC37 for ; Wed, 29 Jul 2009 09:07:05 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlICAHCSb0qEpqxqmWdsb2JhbACCJTCXNQEBAQEBCAsKBxO6JIQQBQ X-IronPort-AV: E=Sophos;i="4.43,288,1246831200"; d="scan'208,217";a="31830028" Received: from cirse-out.extra.cea.fr ([132.166.172.106]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Jul 2009 09:06:35 +0200 Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n6T76YME019884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 29 Jul 2009 09:06:34 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n6T76YeN010743 for ; Wed, 29 Jul 2009 09:06:34 +0200 (envelope-from Pascal.Cuoq@cea.fr) Received: from is005030.intra.cea.fr (is005030.intra.cea.fr [132.166.132.11]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n6T76YRr018751 for ; Wed, 29 Jul 2009 09:06:34 +0200 Message-Id: <60DA2C46-E67F-44BF-9ECC-625461BF10B5@cea.fr> From: Pascal Cuoq To: caml-list@yquem.inria.fr In-Reply-To: <20090729030710.BB3C6BC5C@yquem.inria.fr> Content-Type: multipart/alternative; boundary=Apple-Mail-47--39046413 Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [Caml-list] Physical counterpart to Pervasives.compare? Date: Wed, 29 Jul 2009 09:04:53 +0200 References: <20090729030710.BB3C6BC5C@yquem.inria.fr> X-Mailer: Apple Mail (2.935.3) X-Spam: no; 0.00; cuoq:01 cuoq:01 pervasives:01 pervasives:01 trivial:01 trivial:01 haskell:01 ocaml:01 ocaml:01 haskell:01 edgar:98 edgar:98 polymorphic:01 polymorphic:01 wrote:01 --Apple-Mail-47--39046413 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Edgar Friendly wrote: > > Elnatan Reisner wrote: >> Is there something that can complete this analogy: >> (=) is to (==) as Pervasives.compare is to ___? >> >> That is, is there a polymorphic total ordering with respect to >> *physical* >> entities, rather than to their structure? >> > No, but it'd be pretty trivial to implement through the C interface. No, it would not be trivial to implement, because you would not want the order of two values to change each time one is moved from the minor heap to the major heap or when the major heap is compacted. The article linked below is about this kind of topic (among other things), in the context of Haskell. http://research.microsoft.com/en-us/um/people/simonpj/papers/weak.htm The simple solution is to number at creation the objects that you want to physically compare, using an additional field. > If you had to stay in the OCaml realm, you might be able to do [let > phys_comp (x:'a) (y:'a) = (Obj.magic x) - (Obj.magic y)], but it > depends > on the exact implementation of (-) on your architecture, as it may > produce a value that's not an OCaml int when given non-ints as input. As an additional general remark, it is a bad idea to use "x - y" as an implementation of "compare x y" because of overflows. Pascal --Apple-Mail-47--39046413 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Edgar Friendly = wrote:

Elnatan Reisner wrote:
Is there something that can complete this = analogy:
(=3D) is to (=3D=3D) = as Pervasives.compare is to ___?

That is, is = there a polymorphic total ordering with respect to = *physical*
entities, rather = than to their structure?

No, but it'd be pretty trivial to = implement through the C = interface.

No, it would not be = trivial to implement, because you would not want the
order = of two values to change each time one is moved from the minor = heap
to the major heap or when the major heap is = compacted.
The article linked below is about this kind of = topic (among other
things), in the context of = Haskell.


The simple solution is to number at = creation the objects that you want to
physically compare, = using an additional field.

If you had to stay in the OCaml realm, you might be = able to do [let
phys_comp (x:'a) (y:'a) =3D (Obj.magic x) - = (Obj.magic y)], but it depends
on the exact implementation of (-) on = your architecture, as it may
produce a value that's not an OCaml int = when given non-ints as input.

As an = additional general remark, it is a bad idea to use "x - y"
as = an implementation of "compare x y" because of = overflows.

Pascal

= --Apple-Mail-47--39046413--