Fear and loathing of the "perlification" of Smalltalk

Peter William Lount peter at smalltalk.org
Wed Sep 5 00:01:55 UTC 2007


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.

>   
>> 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




More information about the Squeak-dev mailing list