Re: Creating and using arrays - again

On Mar 24, 6:55 am, Jonah Thomas <jethom...@[EMAIL PROTECTED]
> wrote:
> "Mark W. Humphries" <m...@[EMAIL PROTECTED]
> wrote:
>
> > I've always liked that the normal behavior of variable data in Forth
> > is to leave its address on the stack. In most cases I eventually end
> > up going back and refactoring a CREATE DOES> construct into two
> > separate words by naming the former DOES> part promoting it to a full-
> > fledged word on its own. I end up with two words, two names, for two
> > behaviors, which seems natural to me. I can of course add myriad other
> > behaviors by creating other words that take an address parameter.
>
> Say that CREATE normally makes a word that does   address noop .
> And DOES> substitutes an action for the noop.
>
> It sounds like you're saying you like doing
>
> : action .... ;
> CREATE address
>
> And where someone else would use a DOES> child
>
> CREATE address
> DOES> action ;
>
> .... address ....
>
> you instead just do
>
> .... address action ....

The basic factoring pattern of Forth is:  <noun> <verb>
Nouns that denote variable data push a data address onto the stack.
Nouns that denote constant values push a value onto the stack.
Verbs consume addresses and/or values.

In my experience practices that break this pattern, such as an over-
abundance of prefix words like TO, or overriding data behavior with
DOES> lead to messy factoring in the long run.

> So you need 2 commands in your code each time where DOES> uses only one.
> Do that a lot and you use some space. You save the space used by your
> parent word and you can save the extra space in all those CREATEs.
> (Except the CREATEs don't have to use extra space. In an
> indirect-threaded system they can call the code in the parent, which
> finds the address from the return stack and then executes the following
> code. You can rearrange the complexity various ways.) You have to use
> extra code and extra source code.
>
> In exchange for those disadvantages, you get to choose any action you
> like to act on your address, and it takes no extra machinery to set that
> up. You just do it. Ultimate flexibility at the cost of a little extra
> typing and a little extra code.

The size that ultimately matters is the compiled size of the overall
application. An approach that may result in extra code for a single
snippet, can lead to less code overall if it encourages better
factoring of the overall application.

> > My impression is that whether one perceives DOES> as a necessity in
> > Forth has more to do with one's factoring style than anything else.
>
> I can't imagine thinking of DOES> as a necessity. But it can be a nice
> convenience.