[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

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