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

[Felix Klock]

On Mar 5, 2007, at 12:47 PM, Bradley Lucier wrote:

>
> On Mar 5, 2007, at 10:36 AM, William D Clinger wrote:
>
>> Brad Lucier wrote:
>>> I presume that many people might want to use bytevectors as  
>>> described
>>> in this report to increase computational speed and decrease memory
>>> requirements by avoiding boxing/unboxing of objects that might
>>> otherwise be boxed when held in generic vectors.
>>
>> Me too.  I have been assuming that someone would write
>> a SRFI for type-specific numeric vectors together with
>> a portable R6RS reference implementation using bytevectors
>> encapsulated within records.
>>
>> 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?
>
> I haven't looked at the record proposal, so I don't know.

I interpreted the proposal as saying that this hypothetical SRFI  
would be specified in a manner that *allows* an implementation to  
choose a implementation-specific representation that enforces the  
aliasing guarantees you desire.  The hypothetical SRFI would also  
provide a reference implementation that has observationally  
equivalent behavior, but would probably not be able to be similarly  
optimized by standard compilation technology.

(I am assuming that the record system proposed in R^{5.92}RS allows  
for this sort of encapsulation, but I have not verified this.)

-Felix