Re: [r6rs-discuss] Procedure equivalence: the last debate
[+r6rs-discuss] It occurs to me that because of the R6RS procedure equivalence rules, it's impossible to efficiently implement something like `hashtable-map` (which lifts a function to the domain of hash tables) while being strictly conformant. To do so, one must be able to create a hash table with the same equality procedure and hash function as a given hash table. The `hashtable-copy` function does this, but it also copies the associations, which is not wanted in this case. However, in order to create a most-efficient hash table whose equality predicate is `eq(v)?`, you need to invoke `make-eq(v)-hashtable` rather than the general `make-hashtable`. But although it is possible to retrieve the equality predicate using `hashtable-equivalence-function`, and although R6RS guarantees that this procedure returns `eq(v)?` in the relevant cases, you cannot test whether that is what you have! The following code fragment is not portable: (let ((equiv? (hashtable-equivalence-function some-hash-table))) (cond ((eqv? equiv? eq?) (make-hashtable-eq)) ((eqv? equiv? eqv?) (make-hashtable-eqv)) (else (make-hashtable equiv? Code like this actually appears in the R6RS implementation of SRFI 69 at https://code.launchpad.net/~scheme-libraries-team/scheme-libraries/srfi, which suggests that in fact none of the R6RS implementations are making use of this optimization, at least in this kind of case. -- Only do what only you can do. John Cowan co...@ccil.org --Edsger W. Dijkstra's advice to a student in search of a thesis ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Procedure equivalence: the last debate
[Warning: sent to both r6rs-discuss and scheme-reports] John Cowan wrote: The following code fragment is not portable: (let ((equiv? (hashtable-equivalence-function some-hash-table))) (cond ((eqv? equiv? eq?) (make-hashtable-eq)) ((eqv? equiv? eqv?) (make-hashtable-eqv)) (else (make-hashtable equiv? Code like this actually appears in the R6RS implementation of SRFI 69 at https://code.launchpad.net/~scheme-libraries-team/scheme-libraries/srfi, which suggests that in fact none of the R6RS implementations are making use of this optimization, at least in this kind of case. I doubt whether that code really needs to be completely portable. The web site cited mentions only three implementations of Scheme in which the code is alleged to work, along with one more that's semi-supported. It seems to me that it's okay for code to rely on non-portable peculiarities of the small finite number of implementations it claims to support. The original reference implementation of SRFI 69 was non-portable even with respect to R5RS semantics. The purpose of that reference implementation was to provide a good starting point that could be tailored/rewritten to take advantage of implementation-specific features and characteristics. Although the R6RS allows both eq? and eqv? to return #f whenever either argument is a procedure, most implementations of the R6RS provide implementations of eq? and eqv? that are more useful than required by the R6RS. When writing portable R6RS code, however, passing procedures to eq? or eqv? is pretty much limited to caching and other situations where detecting equivalence of procedures is helpful but not absolutely essential. That's one of the reasons I favor changing the R7RS small-language document to make the semantics of eq? and eqv? somewhat closer to the R5RS semantics than to the R6RS semantics. Another reason for making this change is the R6RS requirement that eq? and eqv? behave the same on procedures, which was *not* required by the R5RS. That new requirement has had the practical effect of forbidding the compiler optimizations the R6RS semantics was intended to allow (according to R6RS rationale section 11.5.1). Will ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
