Fear and loathing of the "perification" of Smalltalk

Peter William Lount peter at smalltalk.org
Wed Sep 5 01:03:14 UTC 2007


Mathieu Suen wrote:
> On Sep 5, 2007, at 2:40 AM, Peter William Lount wrote:
>
>> Hi,
>>
>> Mathieu Suen wrote:
>>> >Peter wrote: Oh, well putting it into the virtual machine is the 
>>> best place for it in my view, but that's an implementation detail. 
>>> Why is it the best? Performance and flexibility with all the 
>>> capabilities fully realized.
>>>
>>
>>
>>> No. a  b and c is statement is not literal. What do you want to put 
>>> inside the vm.
>> The vm would simply need to record the values being produced as the 
>> result of each statement into a collection. It's the evaluator that 
>> changes.
>>
>>>
>>> Especially the "."  is only for parsing. So block would have a 
>>> completely different meaning.
>> No, the "." is still only for parsing.
>>>
>>> Suppose you write:
>>>
>>> [a := 3.
>>> a factorial]
>>>
>>> If the compiler is not to stupid the generate bytecode would look like:
>>>
>>> pushConstant: 3.
>>> storeInTemp:0
>>> send: #factorial
>>>
>>> So now how would you expect the VM to detect your ".".
>>> If you expected such a things then you need to change the Compiler 
>>> and the block.
>>>
>> The compiler would need to do something like:
>>
>> pushConstant: 3.
>> storeInTemp: 0.
>> add to collection byte code.
>> send: factorial.
>> add to collection byte code.
>>
>> The "add to collection byte code", assuming you are using byte codes 
>> for the code, would be at the end of each statement and would collect 
>> up the results.
>>
>> Of course you could also rewrite the block (parse tree) at runtime to 
>> perform the sequence of add statements much as the current 
>> implementation does. It really depends on how you want to implement it.
>>
>> Cheers,
>>
>> peter
>>
>
> How do you decide when to add the bytecode?
>
>     Mth
>
>
Hi Mth,

You are still stuck on byte codes eh? That is so 1960's. I invite you 
into the innovation frame of mind, discard what you think you know about 
this topic, and open your eyes wide open and imagine a future with 
powerful blocks. We are just scratching the surface with this one new 
block feature. I've invented ten more powerful capabilities for blocks 
and integrated them so they work well.

There are many ways to implement the two evaluators for blocks. For 
example, depending on your byte code set you could have a bit for a 
flag, or you could duplicate the byte codes with one set for each 
evaluation type. Or you could get rid of byte codes all together which 
is the better approach.

It's important that a system be as dynamic as possible. You may need to 
recompile the block at runtime just before it's evaluated if you insist 
on remaining with the out molded notion of byte codes. But there are 
other ways. One could simply add a byte code marker for statements as 
the "add to collection byte code" above illustrated. There are many 
other ways if you are creative and innovative.

The key is being committed to using blocks for this new style of 
evaluator as well as the old and as well as the other one proposed in 
this thread, you know, "[ a. b. c] valuesConcurrently. Very powerful 
stuff as we move into multi core.

Since you are the one committed to byte codes, as demonstrated by your 
remarks, how about you do the thinking on how best to implement it in a 
system such as squeak. Thanks.

Cheers,

peter





More information about the Squeak-dev mailing list