As a small step towards improving the specifications of words related to
arrays and matrices in the Algorithms of the Forth Scientific Library,
I'd like to propose three requirements for Library code. Note that these
only apply to reviewed Algorithms, although they may also be related to
contents of the various auxiliary files that are relied on by Library
routines.
While these proposals are related to several other issues about array
words and their implementation, I think they can be stated and considered
separately. So far as I have been able to determine, they are completely
consistent with all of the 59 Algorithms presently contained in the
Library, and would call for no change in any of the present Library
contents.
1) The stack effect of executing the name of previously created array or
matrix is to add to the data stack a value occupying one cell. The value
will be used in later accesses to the elements of the array or matrix may
depend on the implementation of array words.
I.e., the stack diagram is A{ ( -- id) , where id might be the address
of the first array element, or the address of a header containing
information about the location and contents of the array, or some other
value that will enable subsequent words to resolve references to the
array. (In the current standard implementation, as provided by the
various fsl-util files, id is the address of the location where the array
or matrix elements are stored, and a header containing information about
the array is located immediately before this.)
2) The word & does not change the depth of the data stack. The stack
diagram could be either ( -- ) or ( id1 -- id2 ), depending on the
implementation provided by some fsl-util file. (The current standard
implementation requires that there is an xt on the stack after & is
executed.)
3) The word & must always be followed by the name of of some previously
defined static or dynamic array or matrix.
I believe this requirement is obeyed by all the existing Library code.
The current standard implementation defines & using state-smart words
related to vectored execution. If that particular behavior is desired,
it should be given a different name, to avoid conflict with alternative
implementations.
These proposals would change the guidelines for the creation and reviewing
of FSL routines in a way that I think should not hinder the provision of
contributions but would broaden the freedom of fsl-util files to provide
the current functionality in alternative ways. I'd appreciate any
comments pro or con.
regards to all cgm
|
