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:
>> 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
>>> 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.
>>> 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.
> How do you decide when to add the bytecode?
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.
More information about the Squeak-dev