[bitc-dev] Type compatibility at application

[Jonathan S. Shapiro]

On Sat, 2006-05-20 at 01:12 +0100, David Hopwood wrote:
> 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.

Actually, it is required both that v be immutable and also that the
element of v being accessed be deeply immutable.

In the example we are discussing, v itself is a parameter and likely to
be immutable. If F is a pure procedure, then the cell mutability of the
element of v only arises under multithreading (which is one reason that
BitC isn't multithreaded).

shap