pipe

Igor Stasenko siguctua at gmail.com
Sun Aug 26 23:29:57 UTC 2007


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?

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.

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.

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.

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.
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.
I think this can save us from wasting a processor cycles just for nothing.
I know that such semantics belongs mainly to compiler, not language
itself, but i just want to point out, how language design influences
the implementation, and how good or bad it can turn out at the end.



More information about the Squeak-dev mailing list