[r6rs-discuss] [Formal] bytevector aliasing severely impedes optimizations

From: William D Clinger <will>
Date: Mon Mar 5 13:25:05 2007

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
Received on Mon Mar 05 2007 - 13:24:57 UTC