On 05/09/07, Peter William Lount <peter at smalltalk.org> wrote:
> The key is in how it's evaluated. With a block that can be chosen at run

Changing evaluation means changing bytecode. Bytecode is produced at
compile time, so either you produce every version possible and choose
at runtime, either you compile nearly nothing and interpret/compile at
evaluation time. Both ugly solutions.

> time whereas with the curly braces it's much more limited since they
> just syntax sugar and don't have the power of the capabilities of the block.

But braces have the semantics of "collection of expressions". Blocks
have the semantics of "block of code which execution is the standard
one, only deferred"

> > If [a.b.c] piped is possible, then [a.b.c] do: [:aStatement|
> > aStatement value] should be possible to, shouldn't it ?
> > Or [a.b.c] addStatement: [d]
> > or [a.b.c] at: 2 put: [e]
> >
> >
> Yes, those are nice additions.

And I would accept them if they used curlies: {a.b.c} addStatement:
[d]. With square braces [a.b.c] it conflicts too much with my
intuitive semantics of blocks.

-- 
Damien Pollet
type less, do more [ | ] http://typo.cdlm.fasmz.org