From: Alessandro Baretta <alex@baretta.com>
To: brogoff@speakeasy.net, ocaml <caml-list@inria.fr>
Subject: Re: [Caml-list] CamlP4 Revised syntax comment
Date: Tue, 29 Oct 2002 18:20:47 +0100 [thread overview]
Message-ID: <3DBEC36F.3070802@baretta.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0210290830380.29872-100000@grace.speakeasy.net>
brogoff@speakeasy.net wrote:
> On Tue, 29 Oct 2002, Pierre Weis wrote:
>>We thus may need a deeper equality to test graph equivalence! (You can
>>argue that = could behave like that, but this is not easy to implement
>>efficiently.)
>>
>>Since this new predicate is inherently costy (we need to keep track of
>>all already visited nodes), a longer name reminiscent of its equality
>>semantics could be ``===''.
>
>
> I hadn't thought of that, and I'm not even sure if you're just pulling my leg,
> but it's a good argument anyways. Is this an abstract point, or has anyone
> really needed a graph equivalence test over recursively defiend values in
> practice?
>
> -- Brian
I have a case where I actually need to test for structural
equality over cyclic data structures--essentially top-down
trees, with an upward link from nodes to their parents.
These structures are necessary whenever the tree traversal
starting point can be any node in the structure. This
happens, for example, when you import a relational database
and model foreign key fields with actual references between
records.
Of course, it is fairly easy to devise a specific equality
test for such cases, but, in general, one such equality
function is needed for every datatype appearing in the
graph. This can get painful if the number of different
datatypes (tables) gets large. In such cases a "graph
equivalence" operator would be a useful bonus. Still, I
don't think this is a major issue with O'Caml.
Alex
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
next prev parent reply other threads:[~2002-10-29 17:21 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-25 19:02 brogoff
2002-10-25 19:25 ` Oleg
2002-10-26 9:27 ` Stefano Zacchiroli
2002-10-26 11:19 ` Daniel de Rauglaudre
2002-10-26 17:38 ` David Brown
2002-10-26 19:27 ` brogoff
2002-10-28 8:38 ` Kontra, Gergely
2002-10-28 9:28 ` Oleg
2002-10-28 9:41 ` Florian Douetteau
2002-10-28 10:04 ` Stefano Zacchiroli
2002-10-28 12:20 ` Daniel de Rauglaudre
2002-10-28 16:53 ` brogoff
2002-10-28 16:56 ` Alexander V.Voinov
2002-10-29 18:15 ` Gérard Huet
2002-10-29 18:47 ` Alexander V.Voinov
2002-10-29 20:53 ` Damien Doligez
2002-10-29 21:30 ` M E Leypold @ labnet
2002-10-29 21:42 ` brogoff
2002-10-29 11:30 ` Pierre Weis
2002-10-29 16:48 ` brogoff
2002-10-29 17:20 ` Alessandro Baretta [this message]
2002-10-30 17:49 Arturo Borquez
2002-10-31 9:21 ` Daniel de Rauglaudre
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=3DBEC36F.3070802@baretta.com \
--to=alex@baretta.com \
--cc=brogoff@speakeasy.net \
--cc=caml-list@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