Idea for a possibly better Collection occurrencesOf method.

Klaus D. Witzel klaus.witzel at cobss.com
Wed Sep 13 23:43:08 UTC 2006


Hi Hans-Martin,

thank you for sharing your experience. Now I know whom to ask for a code  
review on iterators who make a living in contexts ;-)

I started with the idea to keep the three arguments aBlock, index and  
limit located where they are and rewrite index+1 in-place.

So this is invariant at #commonSend time.

And this is invariant at #commonReturn time (which discards possible  
return values with a simple ifFalse:).

And it implies linear code in the primitive; the ifTrue:'s ifFalse:'s all  
test only successFlag. A straight forward implementation of Stream>>#next  
concatenated with BlockContext>>#value:.

Since the primitive either successfully populates and activates aBlock  
(like #value: does, initialIP, argument) or else fails, it does not need  
to know about any previous bytecode position.

Also invariant: the primitive is called by both, #commonSend and  
#commonReturn, and always does the same - except when index <= limit no  
longer holds.

The latter, (index <= limit) not, has 2 cases

at #commonSend time the receiver object is returned

at #commonReturn time the receiver object is returned

Invariant, again.

/Klaus

On Wed, 13 Sep 2006 21:47:48 +0200, Hans-Martin Mosner wrote:

> danil osipchuk schrieb:
>> But I wonder, if VAST problems with seaside are related to something
>> like that ;)
> Not primarily. VAST uses a single stack per process instead of Context
> objects as the Smalltalk-80 derived systems (Squeak and VisualWorks) do,
> and the stack can not be safely manipulated by non-VM code. I've tried
> it quite hard, and I did not find a way to implement continuations
> correctly.
>
> The iterator primitive could be implemented with Context objects, but
> there are some tricky issues:
> 1. There needs to be a slot in a context where the iteration variable
> can be stored. One possibility would be to keep the block, collection,
> limit and current index on the stack of the calling context, instead of
> popping them off the stack.
> 2. The return value from the block needs to be discarded somehow.
> Normally, every return from a method or block pushes the result onto the
> caller's stack. The problem is that the primitive can only handle the
> activation of the block, not its return.
> 3. The primitive needs to ensure that the return will happen to the
> right place so that the loop can continue, preferably just to the
> position of the send bytecode. But since bytecodes may be 1 or more
> bytes long, it is difficult for the primitive to find out what's the
> correct place.
>
> Overall, I think that the performance and readability improvements
> gained by such a primitive might not be worth the effort.
>
> Cheers,
> Hans-Martin
>
>





More information about the Squeak-dev mailing list