On Sep 5, 2007, at 2:01 AM, Peter William Lount wrote:

> Damien Pollet wrote:
>> 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.
>>
> Compile time is whenever you wish it to be with Smalltalk.
>
> Nonsense, you've locked your brain onto  a particular  
> implementation approach before thinking it all through. Blocks  
> simply have a means of evaluation that either returns the last or  
> collects all the values. The rest is done in the primitives. This  
> could be implemented without adjusting how the byte codes are  
> compiled - only statement boundaries would need to be made clear in  
> the even that any optimizations eliminate the boundaries. It  
> depends on how you implement the virtual machine.

Well! Read the Blue book if you want to know about the VM.
But stop talking about VM, bytecode, compiler and so on if you want  
to talk about conceptual things.

So the question is do we consider block as list of statements or just  
a chunk of code.
Now if you take a look of the functional world you will see that  
lambda are never consider as a list of statements.

If you want a block to be a list of lambda then you make a conceptual  
mistake.
Build a new abstraction if you want to have statements list but don't  
use the block.

	Mth

>
>>
>>> 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"
>>
>>
> Just because the curly braces were simple to implement doesn't mean  
> that they should be done that way! Just because it's easy is what  
> leads to perlification! It's the dark road to syntax hell.
>
> A key design principle is to have the language the top priority and  
> the virtual machine implementation subordinate to that, not the  
> other way around as you propose. The curly braces solution for  
> Squeak has committed the essential error in the design of Perl,  
> make an easy syntax change to make life for the compiler and  
> virtual machine easy. Unfortunately this brings hell to programmers.
>
>>>> 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.
>>
> Nonsense. It's very clean and eliminates the need for special  
> syntax with the curly braces. There is no need for the curly braces  
> when blocks can do the job.
>
> Cheers,
>
> Peter
>
>