CLIP some more!

[btanksley@hifn.com]

From: iepos@tunes.org [mailto:iepos@tunes.org]

>> [variable stack effect words]

>> Generally speaking, if you play with more than 3 stack 
>> elements, your code
>> needs a redesign. 

>This would be true I guess in most Forth systems and in Joy.
>But, I still wonder if maybe playing with more things than 3 on the
>stack wouldn't be so bad if the system were designed for it from
>the ground up...

It's not so much the system as it is the human brain.  It's generally easy
to hold seven static, sequential items in short-term memory; however, if any
random accessing needs to be done, or if the items aren't really static,
four is the limit.

It's also interesting that three is the number of items which most people
can recognise as one gestalt; any more items, and your mind has to
subdivide, which takes some more time.

>Either way, it does seem important that the system provide some form
>of list mechanism, so that (roughly speaking) multiple things
>could be passed around as if they were one thing. For this purpose,
>I think the pure-program-that-pushes-some-things-onto-the-stack
>makes a good substitute for a list, so that a system would not need
>special primitives for lists

Yes, this is true.

>(actually, this seems to be the way Joy
>does it)... 

Huh?  Joy _does_ have special primitives for lists.

>I'm still uncertain about how to handle the issue of the size of
>the list, whether it will be explicitly contained as the first member
>or if it will be accessible only by some magical "length" program that
>takes a program and tells how many things it would push onto the stack.
>I'm leaning toward the first approach (length contained as an explicit
>member, the first of the tuple).

The second approach isn't workable in general.  It's bad enough that some
programs have variable stack effects, but to add insult to injury, even
programs with constant stack effects may actually have undecidable stack
effect.

>> >If I do end up using unified lists (and this is likely), the main
>> >primitives will just be "wrap" and "unwrap" (in the absense of
>> >"reverse", "map", "concat", and things)... If one wants to do
>> >more complex things with lists, then the thing to do is to unwrap
>> >them first and then use the variable-stack-effect words (and
>> >then wrap it back up again, if needed) ...

>> You haven't done much Forth coding, have you?  The 
>> variable-effect words are
>> so destructive to understanding that I have seriously never 
>> seen any in any Forth code.

>Well... indeed, I haven't done much Forth coding; actually, I have
>done no Forth coding... someday I'll have to dig up an interpreter,
>I guess.

Possibly.  It's not important, though, since the kind of experience it takes
to really understand that doesn't come from a little Forth programming; you
have to either be really experienced or rely on someone else's experience.

A book would be a great way to get that experience, really; one of my
favorites is Leo Brodie's "Thinking Forth" and "Starting Forth".

>Oh, by the way, I've been working on a little Joy-like interpreter,
>which may find itself in some form in the IOCCC if I get finished
>in time :-)

Grin.

>Sometime I'd like to make a small speedy Joy-like system, that is not
>based on a slow interpreter loop. But this is probably too ambitious,
>as I've never written or hacked compilers. 

I don't know.  I'm writing something like this myself, and I'm basing it on
Chuck Moore's "Machine Forth", which makes writing the compiler utterly
trivial.  My friend, Sam Falvo, is writing an optimiser which seems to be
working incredibly well -- he's written three complete rewrites in the past
four days, each of which was completely functional in its own way (meaning
that the first prototypes didn't handle all of the optimizations we needed).

Jeff Fox discusses Machine Forth at http://www.ultratechnology.com; look
especially at the "Forth" link.

>- "iepos" (Brent Kerby)

-Billy