I am posting this as an individual member of the Scheme community. I am not speaking for the R6RS editors, and this message should not be confused with the editors' eventual formal response.
Brad Lucier quoting me: > > If you or I were to write that SRFI, it would solve the > > aliasing problem without even having to mention it. > > Will it? The components of two records, one holding ints, one > holding floats (or, here we go, one holding *both* floats and ints, > which is what is really envisaged by this proposal) could not be the > same bytevector? There is no such restriction in general, but the SRFI can (for example) require the SRFI's homogeneous vectors of unboxed 32-bit ints to be disjoint from the SRFI's homogeneous vectors of 64-bit ints, and require both to be disjoint from the SRFI's homogeneous vectors of IEEE doubles, just as the R5RS requires strings to be disjoint from vectors. Then aliasing between those three kinds of homogeneous numeric vectors would be just as impossible as aliasing between strings and vectors. If the reference implementation were to make proper use of the sealed and opaque features of the proposed record system, manufacturing a fresh non-escaping bytevector for each homogeneous numeric vector, then a Sufficiently Clever Compiler could figure all that stuff out just by deducing it from the reference implementation. More realistically, implementors who wanted to provide efficient support for the SRFI would build that knowledge into their compilers. Applications like this are the raison d'etre for the sealed and opaque features of R6RS records. Will _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
