Per Bothner <per@bothner.com> writes:

> The problem is I would like to allow the following to return true
> (as it does in Kawa):
>
> (define (maybe-negate negp)
>    (if negp (lambda (x) (- x))
>        (lambda (x) x)))
> (eq? (maybe-negate #t) (maybe-negate #t))
> ;; Likewise for eqv?

I don't understand why this should be a problem.  The semantics proposed
by Will retain the notion of a location tag, and merely change it from
being the procedure's identity (which eq? test for) to being an extra
trait of a procedure (which eqv? uses to report operational equivalence
despite differing (or nonexistent) identity).  But neither R5RS nor
Will's proposal require eq? or eqv? to return #f when the location tag
differs; if an implementation can solve the halting problem and always
detect operationally equivalent procedures, by all means it ought to be
allowed to. :)

(And it is, from what I see in R5RS and R7RS-small/draft9.)

For the record, my view on eq? and opinion on Will's proposal is as
follows.

eq? is a (typically) more efficient eqv?, which however is only
guaranteed to work right on some types.  This means I can always use it
in place of eqv? where I know it won't receive arguments of the wrong
types, and this will give my program a certain efficiency enhancement.

Will's proposal removes procedures from the set of types on which eq? is
guaranteed to work, so this decreases the frequency of places where I
can use it.  On the other hand it allows some compiler optimizations.

I have little knowledge and experience on 1) the frequency of cases
where the added restriction will prevent me from using eq?, 2) the
extent of optimizations allowed by the added restriction.  So basically
I cannot weight the decision on its own worth, and will have to trust
others' knowledge and experience on those two points.  I'm slightly
inclined to believe, however, that the decrease in places where eq? is
allowed will be substantial, so I'm not sure if the allowed
optimizations are worth it.  (I didn't look into them in depth though,
so I refrain from making strong claims.)

In addition to all that, there is the problem of having to go through
old code-bases, detecting and removing all usages of eq? which are now
invalidated.  This will probably be a tiresome effort for those who want
to do it, so I would say that the proposed change should only be done
once we are *sure* that it will result in higher total efficiency in
Scheme programs, as per the two points mentioned in the previous
paragraph.  (Please tell me if there are more practical implications of
the proposals than those two points; I don't see any.)

Taylan

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports