Josh Grams josh@[EMAIL PROTECTED]
wrote:
> C. G. Montgomery <cgm@[EMAIL PROTECTED]
> wrote:
>> Michael michael.kalus@[EMAIL PROTECTED]
wrote:
>>
>>> Is & a forth word? How about &! ?
>>
>> The words & and &! are among those defined in the fsl-util files in the
>> Auxiliary code provided with the Library:
>> http://www.taygeta.com/fsl/scilib.html
>>
>> Unfortunately, these and a number of other FSL words are defined only
>> by a particular implementation rather than fully specified, so other
>> implementations may provide the same functionality differently. In
>> other words, full phrases such as the ones you quote, have standard
>> effects, while the individual words may behave differently.
>
> Bleh. That's not very helpful. 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.
> An `elements` reference is sufficient to access the elements of the
> array, but words which modify the array's structure need a full array
> reference. You can only get an array reference for dynamically
> allocated arrays, as the structure of a statically allocated array can't
> be modified.
>
> &! ( elements array -- ) \ set ARRAY so that it refers to ELEMENTS
> }malloc ( array u -- ) \ allocate U elements for ARRAY
> }free ( array -- ) \ free the elements of ARRAY
>
> Or does this abstraction break down in some cases?
>
> --Josh
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.)
But of course anyone could make any change he pleases to the fsl-util
words and then modify the Algorithms so that they behave correctly, so
the issue is more philosophical than pragmatic. And Forth allows free
choice when it comes to Philosophy vs. Pragmatism. ;-)
regards cgm
|
