& in A rationale for ARRAYs in the Forth Scientific Library
Michael
http://www.taygeta.com/fsl/docs/fsl_arrays.html
I found this phrase:
& name{ #elements }malloc
What does the character & indicate at the beginning of the line?
In that document it is also used this way:
a{ & b{ &!
Is & a forth word? How about &! ?
Michael
C. G. Montgomery
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.
In any case, reading a fsl-util file along with "A rationale for arrays"
is probably a practical necessity. Similarly, "A rationale for
Structures" may require reference to the Structures package, structs.seq.
(If you are just beginning to explore the FSL, feel free to let me know by
email if you encounter puzzles.)
regards cgm
Josh Grams
> 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 )
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
C. G. Montgomery
> C. G. Montgomery <c...@physics.utoledo.edu> wrote:
>> Michael michae...@onlinehome.de 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
Michael
On 10 Mai, 01:51, "C. G. Montgomery" <c...@physics.utoledo.edu> wrote:
...
> > What does the character & indicate at the beginning of the line?
...
> 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
...
Aha, now I know better how to use FSL.
Found:
fsl-utilg.fth
An auxiliary file for the Forth Scientific Library
For GForth
Thank you very much.
Michael
Josh Grams
>
>> 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
Bruce McFarling
> 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.
However, its not the stack effects that are abstracted in the FSL
utilities, but the structure of the entities that the stack items
refer to.
If you want to have:
array{} ( index -- array{index} )
it is unambiguous that its:
: array{} ( index -- array{index} ) array{ SWAP } ;
What's at issue in the question of whether it can be assumed that all
FSL arrays are structured like the arrays defined in the fsl-util
files is how to write new words like ``}''.
I've noted my position on this before at length ... there should be a
compiler constant that says whether or not that can be assumed.
If the compiler constant is present and TRUE, then it can be assumed
that the arrays are structured like the fsl-util file arrays, and the
carnal knowledge of that structure can be used when writing new
``}foo'' words ... if there is no compiler constant, or if it is
false, it cannot be assumed, then new ``}foo'' words must be written
in terms of existing words that operate on ( array ) and ( element )
items on the stack.