What does 'eqv' do exactly?

[John M. Dlugosz]

I've searched the archives, but did not see a good explanation of what eqv does, and what is meant by snapshotting in the description of the synopses.

Can anyone explain it (with examples?) or point to an existing treatment, please?

--John

[Jon Lang]

John M. Dlugosz wrote:
> I've searched the archives, but did not see a good explanation of what eqv does,
> and what is meant by snapshotting in the description of the synopses.

Try this: http://markmail.org/message/vub5hceisf6cuemk

> Can anyone explain it (with examples?) or point to an existing treatment, please?

Try this: http://markmail.org/message/mincjarbbfqhblnj

--
Jonathan "Dataweaver" Lang

[Adriano Ferreira]

I think the best explanation so far is at Synopsis 03, section
"Comparison Semantics"

http://feather.perl6.nl/syn/S03.html#Comparison_semantics

[Jon Lang]

I suspect that at the core of John's question is the fact that nobody
has ever actually said what 'snapshot semantics' is: it's a term
that's been tossed around with the assumption that people already know
its meaning.

My own understanding of it is that "snapshot semantics" involves
looking at an immutable copy of an object (a "snapshot" of it) instead
of looking at the object itself. That said, my understanding may be
flawed.

--
Jonathan "Dataweaver" Lang

[John M. Dlugosz]

Binary |eqv| tests equality much like |===| does, but does so with
"snapshot" semantics rather than "eternal" semantics. For top-level
components of your value that are of immutable types, |eqv| is identical
in behavior to |===|. For components of your value that are mutable,
however, rather than comparing object identity using |===|, the |eqv|
operator tests whether the canonical representation of both subvalues
would be identical if we took a snapshot of them right now and compared
those (now-immutable) snapshots using |===|.
"

That's exactly what I find lacking. Hence the desire to find someone to
explain that, and then write a better description to file away for
future use.

--John

[John M. Dlugosz]

Yes. How is a snapshot different from the object?

[David Green]

I would explain it as: "eqv" compares the "value" of two objects --
"snapshot" meaning the value at a specific time, since of course the
value might changes at different times while the object remains the
same. It's what other languages would call "==" (however they spell
"=="); in P6 "==" was already taken for numeric equivalence. So "$a==
$b" means "+$a eqv +$b" and "$a eq $b" means "~$a eqv ~$b".

Of course, for numbers and strings, the value/snapshot isn't different
from the object; but suppose I create two date-objects, $d1 and $d2,
both set to 2008-05-04. $d1 eqv $d2 would be true, but $d1===$d2 will
be false, because $d1 and $d2 are different objects (probably -- of
course, the implementation could be designed to notice that the dates
are the same and thus re-use the same object; it could also override
the object's identity (aka its .WHICH) to make it look like both
objects were really the same object). I believe the default identity
for objects will be something like P5's unique memory address.

Presumably the snapshot then takes whatever an object claims to be its
"value" and reduces any mutable parts into immutable values, until it
end up with something that consists wholly of immutable values.

-David

[TSa]

HaloO,

John M. Dlugosz wrote:
> Yes. How is a snapshot different from the object?

My interpretation is that === is an equivalence relation
on a WHICH set and eqv is an equivalence relation on a
WHAT set. A "mutable value" is an element of a (n>1):1 mapping
of a subset of WHAT to a single WHICH. A 1:1 mapping is an
"immutable value". A 1:(m>1) mapping has no funny name. Neither
has a n:m mapping. IOW, a value is a subset of the cartesian
product of the WHAT and WHICH sets. A snapshot of a value is
picking one element of that set. For == the WHAT is Num and for
eq it is Str. Both map 1:1 to their respective WHICH sets. The
=:= checks binding of names so it is an equivalence relation
on a set of names. But I'm unsure if such a set is denoted with
WHO or VAR. But I tend to think it's the latter.

Regards, TSa.
--

"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan