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
|