pipe

Igor Stasenko siguctua at gmail.com
Mon Aug 27 16:16:15 UTC 2007


On 27/08/07, Jason Johnson <jason.johnson.081 at gmail.com> wrote:
> On 8/27/07, Igor Stasenko <siguctua at gmail.com> wrote:
> > Cascade is useful. It allows me to write code like that:
> >                 ogl
> >                 glTexParameteri: GLTexture2d with: GLTextureMinFilter
> > with: GLLinear;
> >                 glTexParameteri: GLTexture2d with: GLTextureMagFilter with: GLLinear;
> >                 glTexParameteri: GLTexture2d with: GLTextureWrapS with: GLClamp;
> >                 glTexParameteri: GLTexture2d with: GLTextureWrapT with: GLClamp;
> >                 glPixelMapfv: GLPixelMapIToA with: 2 with: (FloatArray with: 0.0 with: 1.0).
> >
> > But at the same time it stinks because you don't using the evaluation
> > result of previously sent message, you simply drop it. And from this
> > point i feel that something wrong with such design. Why computer needs
> > to waste cycles to evaluate result of message when its simply not used
> > at the end?
>
> What are you talking about?  ; and . are both sequencing operators.
> Sequencing implies that a statement was not for it's results, but it's
> side effects.  And some systems even detect if the result is used and
> drop it if not.
>
> And it's not that cascade "drops" something, it just signals that you
> want the original object instead of the result of the message send.
> If you want the result of the message send you have it, just send your
> message (though parens may be needed to indicate this is a new
> message).
>
> > In contrast , a pipe does not drops evaluation result, but reuses it
> > in expression that follows. From this point i like it more than
> > cascade.
>
> No it doesn't.  It just tells the compiler to treat everything to the
> left a complete expression, without having to use parenthesis.
>
> And it also makes the original object inaccessible, forcing you (in
> some cases) to use temp variables and more of these "side effect"
> statements that you don't seem to like.
>

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.


> > Same with period '.'
> > Each time you placing a period in code, you telling compiler to drop
> > the evaluated result of your expression.
> > Can it be considered as good from computational point of view? Of
> > course its not. You forcing a computer to waste the cycles just for
> > nothing.
>
> Not strictly true.
Yes it is. I can't consider pushing value on stack just for being
popped after method returns as useful operation.
Its simply waste.

>
> > Same with implicit return self from a method. I see a good reasons why
> > i don't want return anything from a method, because it returns nothing
> > useful or meaningful, and never used for continue evaluation in other
> > expressions.
>
> But it might be saved in some variable, what happens then?  Someone is
> going to be quite surprised to get a nil from a method that succeeded.
>

Not at all. for statements like:
a someMessage.
you don't need a result, its dropped.
And for statements like:
var := a someMessage.
You need result.
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.

> > And i think that maybe from computational  point of view, it might be
> > useful to indicate if we need to return result from a method or don't.
>
> If it were even possible to know I still wouldn't find the
> unmeasurably small gains worth the added complexity.
>
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?

> > So, all messages which chained in cascade expressions can be sent with
> > flag 'drop result=true' and same for messages which is the last before
> > period '.'. In other words we can have two forms of 'send' operation
> > (bytecode): Send with return and send without return.
>
> This could be done today (if a bytecode existed for it) by the
> compiler which actually sees if the value is used or not.
>
>


-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list