On 8/27/07, Igor Stasenko <siguctua at gmail.com> wrote:
>
> I'm not pushing idea that cascade stands vs pipe. They both can be
> quite useful, i'm just pointing you out that current implementation of
> sequencing operators do not take in account that result is not used
> and must be dropped. And that stinks.

The issue is you can't always *know* if the result will be used or
not.  When you generator byte codes for a method the variable storing
on the method goes *there*.  Some callers of the method will use it,
some wont.

> Yes it is. I can't consider pushing value on stack just for being
> popped after method returns as useful operation.
> Its simply waste.

It's flexible.  To do anything else is going to require some pretty
big changes/complexity to the current system.

> Not at all. for statements like:
> a someMessage.
> you don't need a result, its dropped.

How exactly is it dropped?  #someMessage will have op codes to return
what ever it returns.  It has to because it can't know what callers
expect.

> And this can be easily detected. If you look at parse tree, a
> statement which beginning from send node (not return node and not
> assignment node) can be considered as send without need a result,
> because its simply dropped at the end.

It's easily detected in the caller, but then it's too late.  Unless
you want to somehow dynamically change called methods byte codes
depending on what the caller expects.

> Unmeasurably?
> Ok, simple example, a bytecode of Collection class>>with:with
>
> 13 <70> self
> 14 <CC> send: new
> 15 <88> dup
> 16 <10> pushTemp: 0
> 17 <E0> send: add:
> 18 <87> pop
> 19 <88> dup
> 20 <11> pushTemp: 1
> 21 <E0> send: add:
> 22 <87> pop
> 23 <D1> send: yourself
> 24 <7C> returnTop
>
> now compare it to (suppose we having sendNoRet bytecode):
>
> 13 <70> self
> 14 <CC> send: new
> 15 <88> dup
> 16 <10> pushTemp: 0
> 17 <E0> sendNoRet: add:
> 19 <88> dup
> 20 <11> pushTemp: 1
> 21 <E0> sendNoRet: add:
> 23 <D1> send: yourself
> 24 <7C> returnTop
>
> for each send in cascade you saving at least two operations: push
> result and corresponding pop. Also, you saving a bytecode size in
> method.
> Are you still thinking that this is 'unmeasureable'?
> Do you want me to write a 'measurer' tool which will parse all current
> methods in squeak and shows a percentage of sends which result is not
> used?

No, I'm not really interested to be honest.  This is a small fish in a
big pond full of things that need to be fixed.  For me much more may
be gained by switching away from a stack based VM altogether (though
I'm not far in my research on it yet :).