[bitc-dev] Type compatibility at application

[David Hopwood]

Jonathan S. Shapiro wrote:
> On Fri, 2006-05-19 at 20:14 +0100, David Hopwood wrote:
>>Jonathan S. Shapiro wrote:
>>
>>>>OK. Are you thinking of a case like:
>>>>
>>>>(define (f x:(vector 'a) #t)
>>>>
>>>>(define vec1:(vector int32)  (vector 1 2 3))
>>>>(define vec2:(vector (mutable int32)) (vector 1 2 3 ))
>>>>
>>>>(define vecApp
>>>>   (begin
>>>>	(f vec1)
>>>>	(f vec2)
>>>>)
>>>
>>>Yes. I am thinking of exactly this. And here is the weird part: if F can
>>>operate correctly on (vector (non-mutable T)), then it will operate
>>>equally correctly on (vector (mutable T)).
>>
>>Isn't the compiled code for F on (vector (non-mutable T)) allowed the
>>optimization of caching vector lookups, while the compiled code for F on
>>(vector (mutable T)) would have to perform every lookup that appears in
>>the source?
> 
> Yes, but I do not expect to ever see such an implementation. The
> overhead of this class of over-specialization is considerable, and the
> necessary supporting runtime complexity is overwhelming.

It's just a form of common subexpression elimination, no?

  // i is a local variable, v is a shared vector
  x := read ith element of v
  some observable side effect, but no change to i or v in this thread
  y := read ith element of v

The second read can be eliminated, but only (in general) if v is not mutable.
I wasn't talking about anything more complicated than this.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>