w...@ccs.neu.edu scripsit:
> Maybe I'm not sufficiently clever, but I don't see how that could work.
> If h is the name of a known local procedure that's referenced only in
> call position, then the compiler shouldn't have to allocate a closure
> *or* a tag for it. (Allocating unique tags is almost as expensive as
> allocating a closure.)
I'm probably missing something here, but if h doesn't need a closure,
what's wrong with using the code address as a unique tag?
> Consider, for example, the reference implementation for SRFI 69
> (Basic hash tables). Its implementation of make-hash-table calls
> appropriate-hash-function-for, which uses eq? (not eqv?) tests on
> comparison procedures to try to identify an appropriate hash function.
Well, `eq?` and `eqv?` must return the same result on procedures anyway.
> (*) Well, almost as well. The general purpose hash function
> refuses to hash procedures. That's just a deliberate bug in
> the reference implementation of the default hash function.
And rightly so by R6RS rules, since using an R6RS procedure as a key
in an R6RS hash table can't possibly work reliably.
> On the other hand, the R5RS semantics for eqv? on procedures
> appears to have encouraged the designer of SRFI 69 to make a
> serious mistake in his design. If you provide a comparison
> procedure but no matching hash function, the implementation is
> supposed to infer an appropriate hash function.
That's not the way I read SRFI 69:
However, an acceptable default is not guaranteed to be given for any
equivalence predicate coarser than equal?, except for string-ci=?.[1]
The function hash must be acceptable for equal?, so if you use
coarser equivalence than equal? other than string-ci=?, you must
always provide the function hash yourself.
[1] An equivalence predicate c1 is coarser than a equivalence
predicate c2 iff there exist values x and y such that (and (c1 x y)
(not (c2 x y))).
> 2. Most of the correct uses that we found were mere efficiency
> hacks. Since the efficiency that's lost by supporting the R5RS
> semantics is considerably more important than the efficiency that's
> gained, the efficiency argument goes against the R5RS semantics.
Doubtless that's true for high-speed implementations, but I'm not sure
the argument generalizes to low-speed ones. A cheap hack that saves
a little bit (like calling the string-specific hash functions when you
know the operands are strings, rather than the general hash function)
is probably even more important to a low-speed implementation.
--
John Cowan co...@ccil.org http://ccil.org/~cowan
The present impossibility of giving a scientific explanation is no proof
that there is no scientific explanation. The unexplained is not to be
identified with the unexplainable, and the strange and extraordinary
nature of a fact is not a justification for attributing it to powers
above nature. --The Catholic Encyclopedia, s.v. "telepathy" (1913)
_______________________________________________
r6rs-discuss mailing list
r6rs-discuss@lists.r6rs.org
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
