Named shufflers (rethought of "factor-way locals" idea)

Idea of local storage in more factor-way still looks interesting for
me. I have followed Slava's advice about "implement and play a
little". It was interesting and not-so-hard experience. Here are
results.

If I want to dismiss annoying "stack micro-management", there is no
need for additional named stacks. Instead of it I had come to
"stack-marking named shufflers" paradigm. I'd like to show it on
simple and common (for me) example from my dns library. What if we
need "virtual" stream that incapsulates some "real" stream and simply
counts number of symbols we are reading?

TUPLE: dns-stream counter ;

: <dns-stream> ( stream -- stream )
	0 dns-stream construct-boa tuck set-delegate ;

M: dns-stream stream-read
	tuck delegate stream-read dup length
	pick dns-stream-counter + rot set-dns-stream-counter ;

In realization of stream-read method we have four different shuffling
words - tuck, dup, pick and rot. It is simpliest solution I've found
with ordinal shufflers. Let's explain true meaning of used shufflers:

1) "tuck" - we need delegate of our stream, but we will need original
tuple in later processing, Lets store it for future use.
2) "dup" - we need length of data, but we also need to return data as
method exit value. Lets store it for future use.
3) "pick" - we need to recall previously saved tuple. But again, we
will need it later, so here we should use "copying" pick and not
"moving" rot.
4) "rot" - we need to recall previously saved tuple. This time it is
last occurense of this value in processing, so here we should use
"moving" rot and not "copying" pick.

That's what I'm calling "stack micro-managment". Not easy logic for
such simple task, I think. And even worse for reading. For comarsion
here is my new suggestion:

M: dns-stream stream-read
	=: self
	delegate stream-read =: data
	length <: self dns-stream-counter + <: self set-dns-stream-counter
	<: data ;

Here I use only two different shufflers - "=: foo" and "<: foo". "=:
foo" is for "mark top of the stack with foo label". And "<: foo" is
for "push here value, previously marked with foo label". So we have
five encounters of this shufflers:

1) "=: self" - we need delegate of our stream, but we will need
original tuple in later processing, Lets mark it for future use with
label "self".
2) "=: data" - we need length of data, but we also need to return data
as method exit value. Lets mark it for future use with label "data".
3) first occurence of "<: self" - we need to recall previously saved
tuple. Lets get it using label "self"
4) second occurence of "<: self" - we need to recall previously saved
tuple. Lets get it using label "self".
5) "<: data" - we need to return result of our method. Lets get it
using label "data".

Looks much more readable for me. No need for tracking of stack depth,
no need for tracking of copying/moving shufflers difference. And
meaningful labels for self-documentation. Just try it.

In attachment I included prototype realisation of this ideas. There
are two additional words for ease of use. ">: foo" is synonim for "=:
drop". And "[> ... ]" is synonim of "[ ... ]" with additional
capability of recalling labels, marked in outter quotation.

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

_______________________________________________
Factor-talk mailing list
Factor-talk@...
https://lists.sourceforge.net/lists/listinfo/factor-talk