[plt-scheme] When does eqv? differ from eq? , from equal?

Dear Shriram,

> I would say that is a distinction between a purist and a pragmatist
> view of functional languages (and I'm a pragmatist, though I've been
> called much worse -- eg, a "worse is better guy" by someone else who
> was a prof while I was still an undergrad <-;).

Well, I am not in the business of name calling nor do I wish to be
involved in such exchanges.

> different claim: modern computer science cannot survive without cost
> models.

I do believe that the basic thesis you profess is sound. Cost models
are essential to our discipline. This, however, does not mean that we
must abandon our abstractions every time a small gain can be made.
Such a greedy approach, in general, is likely to ignore better
solutions that take longer to be developed.

So, is thinking in terms of pointer equality really desirable in this
case? In a very pragmatic sense, is the difference in performance
large enough to justify maintaining a primitive that forces us to
think about pointers? If the answer to this is yes, then let's see the
numbers....the empirical studies. Point me to them. I am sure I can
navigate the issues from there.

I am really not trying to be rhetorical or a purists here nor am I
attacking a position. I am seeking to understand how strong the
evidence is that drives implementors to break the abstraction barrier
provided by Scheme. In other words, how do we justify having to think
about pointers in this case? Why not just have eqv? and be done with
it?

What sense does the test below make?

> (eq? 10000000000 10000000000)
false

It only makes sense if we think about pointers and that seems
unfortunate, but maybe you can present evidence that makes this a
necessary compromise. Does the comparison of two registers in constant
time provide us with significantly superior performance over what eqv?
must do for typical applications?

-- 

Cheers,

Marco