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
|