Re: [Scheme-reports] clarification of proposal for eqv?/eq? on procedures

[Alexey Radul <axch@x>]

I'm afraid I do not have the wherewithal to weigh in on the technical
merits of Will Clinger's proposal (as opposed to reversion to R5RS
status quo).  The practical effect of the proposal is permitting an
optimization, whose value I cannot evaluate; at the cost of
programmers moving more comparisons to eqv? instead of eq?, the
performance hit of which I also cannot evaluate.

Philosophically, I see the situation as follows: In Scheme as it now
stands, eqv? is the custodian of identity.  eq? is an approximation to
eqv?, which gains performance at the cost of exposing the fact that
numbers and characters may be implemented with a complicated selection
of underlying representations.  The philosophical essence of Will
Clinger's proposal, as I understand it, is to admit that procedures
may also be implemented with a complicated selection of underlying
representations.  This is certainly true now, but perhaps wasn't as
obvious, in the early days, as the situation with numbers.

Therefore, I do not object to this proposal on technical grounds, but
for procedural reasons I am hesitant to endorse it.  In particular, I
believe that Working Group 1 would be overstepping its bounds in
implementing this proposal now, without specific direction to that
effect from the community or from the Steering Committee.[*]  Alex
Shinn's proposal, on the other hand, is harmless both technically and
procedurally.  On the latter point, in fact, it is ambiguous whether
"R5RS status quo" or "Alex Shinn's proposal" is the correct
interpretation of the combination of WG1's voting record with the
decision to restore R5RS semantics for eqv? on procedures.

$0.02,
~Alexey

[*] This is an opinion of the author, and does not represent the
official position of WG1, the SC, the NSF, the NIH, MIT, or any other
person or entity whatsoever, whether acronymical or otherwise.


On Sat, Jun 8, 2013 at 9:36 PM, Alex Shinn <alexshinn@x> wrote:
> It was pointed out that my counter to Will's proposal may
> not have been clear.
>
> I propose we restore the semantics of eqv? and eq? on
> procedures to IEEE/R5RS as the WG had intended.
>
> From this we make only one change, which is what the
> WG voted on in ballot item #467, which is that eqv? may
> make a broader distinction than eq?.  However, this is
> in the context of retaining the R5RS semantics for eq?
> on procedures, so effectively we will duplicate the
> same semantics for eqv? and eq? on procedures.
>
> The change is largely ideological, and would make it
> easier should a future standard wish to make eq?
> unspecified on procedures.  It would only break R5RS
> programs in very pathological cases, and only in
> implementations which as yet do not exist.
>
> Unfortunately, not using eqv? to define eq? on
> procedures becomes clumsy.  A potential specification
> is as follows, though I'm open to suggestions for
> improvement:
>
> ----
> The eqv? procedure returns #t if:
>
> * obj1 and obj2 are procedures whose location tags are
>   equal (section 4.1.4).
>
> The eqv? procedure returns #f if
>
> * obj1 and obj2 are procedures that would behave
>   differently (return different values or have different side
>   effects) for some arguments.
>
> ...
>
> On symbols, booleans, the empty list, pairs, records, and
> non-empty strings, vectors, and bytevectors, eq? and eqv?  are
> guaranteed to have the same behavior. On procedures eq? returns
> true if the arguments' location tags are equal, and returns false
> if the arguments would behave differently for some arguments. On
> numbers and characters, eq?'s behavior is
> implementation-dependent, but it will always return either true
> or false, and will return true only when eqv?  would also return
> true. On empty strings, empty vectors, and empty bytevectors, eq?
> may also behave differently from eqv?.
> ----
>
> Finally, in addition to this, WG2 will include a declare
> syntax to specify various standard optimizations.
> This is of great practical use, and is likely the best way
> to provide R6RS-style safety guarantees.  Among the
> declarations provided will be one which allows for eq?
> to be unspecified on procedures.
>
> --
> Alex
>
>
> _______________________________________________
> Scheme-reports mailing list
> Scheme-reports@x
> http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
>

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