C. G. Montgomery <cgm@[EMAIL PROTECTED]
> wrote:
> Josh Grams josh@[EMAIL PROTECTED]
wrote:
>
>> How about putting it this way?
>>
>> name{ ( -- elements )
>> & ( "array-name" -- array )
>
> It could be that name{ returns not the address of the array data but
> rather the address of related information (type, number of elements,
> etc.). That information would be used by } so that name{ i } does
> indeed return the address of the ith element of the array, as it must.
>
> & in the original implementation produces an execution token, but could
> be a noop.
>
> I believe such implementations exist and work correctly.
Sure, but unless you interpret the stack comments in a very limited
fahion, they work fine for those situations. 'elements' and 'array' are
"one or more items on the data stack" (or maybe just one item?). They
contain (at least) the information required to access (respectively) the
elements of the array and the structure of the array. They may or may
not be the same type on a given implementation.
> The essential point is that the Algorithms in the FSL always use the
> array-related words in phrases which have well-defined effects. There
> are two different positions which be taken. The first is that each word
> of those phrases should behave exactly as in the original
implementation.
> The second is that any implementation need only reproduce the behavior
of
> the full phrases, not necessarily of each individual word. My own
> personal preference is for the second position, since it allows more
> freedom to developers without reducing the usefulness of the algorithms
> themselves. (I can say that I know of no case where the reviewing
> process for the FSL encountered problems related to the choice between
> these positions.)
My position is somewhere between those two extremes, and is distinct
from both. I hold that you can have somewhat abstract stack effects
without unduly restricting implementation techniques. The ANS standard
does this with control-flow words, for instance. Forth in general is
specified in terms of a relatively concrete VM model, and I for one
would rather stick with that paradigm.
Just saying, "by some magic, these five phrases work", isn't
necessarily helpful if I want to do something slightly different.
What if I have an index on the stack? Does "name{ swap }" work?
Or do I have to do ">r name{ r> }" instead?
Disclaimer: I'm not an FSL user. But this is the sort of thing that
would make me more likely to use a library rather than write something
from scratch...not a big deal, but lowering the entry barriers never
hurts...
OK, I'll drop the subject now.
--Josh
|
