From: Christophe DEHLINGER <christophe.dehlinger@ifp.fr>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] type of == - Bayesian Filter detected spam
Date: Tue, 19 Apr 2005 09:12:13 +0200 [thread overview]
Message-ID: <4264AF4D.8080308@ifp.fr> (raw)
In-Reply-To: <200504181528.29618.jon@ffconsultancy.com>
Jon Harrop wrote:
>Assuming this is for an OCaml-only program, it sounds as though the "other"
>possible types 'a and 'b should be put into a single variant type. Then you
>can use "'a -> 'a -> bool" with "'a = your variant type". Does that make any
>sense? :-)
>
>
>
Alas, this does not work for me. This is for an OCaml-only module, in
which the "other" types are all instances of one polymorphic mutable
record type, but the number or exact values of these instances are not
known within the module and may be pretty much anything.
Fortunately, I have an easy workaround in my case, but it can't really
be generalized. The polymorphic record type contains a "node" field
(which is a non-polymorphic mutable record). I know that two records
cannot share the same physical node, so I basically use the node as a
unique identifier for the records:
type ('a, 'b) my_record_type = { ... ; node : node_type ; ... }
let my_eq : ('a, 'b) my_record_type -> ('c,'d) my_record_type -> bool =
fun x y -> x.node == y.node
Obviously, this method only works if you have such a unique identifier
for every object you have to compare. If this node field hadn't been
there, I would have been stuck with either cheating with the Obj module,
or artificially adding a unique identifier to each record (like an int
or a unit ref). The latter would have been quite frustrating, because it
would cost execution time + memory + readability only to get around the
arguably artificial typing limitation of == .
Christophe
__________________________
Ce message (et toutes ses pièces jointes éventuelles) est confidentiel et établi à l'intention exclusive de ses destinataires. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'IFP décline toute responsabilité au titre de ce message.
This message and any attachments (the message) are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. IFP should not be liable for this message.
Visitez notre site Web / Visit our web site : http://www.ifp.fr
__________________________
next prev parent reply other threads:[~2005-04-19 7:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-18 9:18 type of == Christophe DEHLINGER
2005-04-18 11:27 ` [Caml-list] " Jon Harrop
2005-04-18 12:11 ` Andreas Rossberg
2005-04-18 13:10 ` Christophe DEHLINGER
2005-04-18 14:28 ` Jon Harrop
2005-04-19 7:12 ` Christophe DEHLINGER [this message]
2005-04-18 16:16 ` Remi Vanicat
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4264AF4D.8080308@ifp.fr \
--to=christophe.dehlinger@ifp.fr \
--cc=caml-list@yquem.inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).