Lazy evaluation: overloading the assignment operator?

[Diez B. Roggisch]

sturlamolden schrieb:
> Python allows the binding behaviour to be defined for descriptors,
> using the __set__ and __get__ methods. I think it would be a major
> advantage if this could be generalized to any object, by allowing the
> assignment operator (=) to be overloaded.
> 
> One particular use for this would be to implement "lazy evaluation".
> For example it would allow us to get rid of all the temporary arrays
> produced by NumPy.
> 
> For example, consider the expression:
> 
>  y = a * b + c * d
> 
> If this expression is evaluated bya Fortran 90/95 compiler, it will
> automatically generate code like
> 
> do i = 1,n
>    y(i) = a(i) * b(i) + c(i) * d(i)
> enddo
> 
> On the other hand, conventional use of overloaded binary operators
> would result in something like this:
> 
> allocate(tmp1,n)
> do i = 1,n
>    tmp1(i) = a(i) * b(i)
> enddo
> allocate(tmp2,n)
> do i = 1,n
>    tmp2(i) = c(i) * d(i)
> enddo
> allocate(tmp3,n)
> do i = 1,n
>    tmp3(i) = tmp1(i) + tmp2(i)
> enddo
> deallocate(tmp1)
> deallocate(tmp2)
> do i = 1,n
>    y(i) = tmp3(i)
> enddo
> deallocate(tmp3)
> 
> Traversing memory is one of the most expensive thing a CPU can do.
> This approach is therefore extremely inefficient compared with what a
> Fortran compiler can do.

I fail to see where laziness has anything to do with this. In C++, this 
problem can be remedied with the so called temporary base class idiom.

But this has nothing to do with laziness, which does not reduce the 
amount of code to execute, but instead defers the point of execution of 
that code.

And AFAIK the general overhead of laziness versus eager evaluation does 
not pay off - haskell is a tad slower than e.g. an ML dialect AFAIK.

Diez