> Not that I care much about SCHEME-REPORT_ENVRIONMENT or > NULL-ENVIRONMENT either, but isn't their > purpose to be as backward-compatible as possible, ...
We could have required more backward compatibility but opted instead to make the environments consistently bind the identifiers defined in the r5rs report to the compile- or run-time values of their r6rs counterparts, where r6rs counterparts exist. The only other consistent treatment would have been to require all of the bindings in these environments to have their r5rs values, and we felt that would be too burdensome. For example, in the r5rs environment, internal definitions would have to have letrec rather than letrec* semantics, real? would have to return true for 1.0+0.0i, eqv? would have to work as it did in r5rs on complex numbers and procedures, read would have to be case insensitive, and all of the effect-only procedures and syntactic forms would have to return exactly one value, even if an implentation's r6rs counterparts return, say, zero values. Furthermore, the r5rs environment would have become inconsistent with what one could build by importing selected bindings from the r5rscompat and r6rs libraries. For consistency, we'd therefore have had to make r5rs much larger to incorporate r5rs bindings for anything that changed between r5rs and r6rs. A better solution might have been to omit the scheme-report-environment and null-environment procedures from the report and wait for someone to provide truly backward-compatible versions as a portable library. Perhaps someone will do so anyway. Kent _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
