[174] 2021-01-13 03:56:09 MitraArdron wrote:

requestClarification - write-cell-mem undefined

In the test cases for ALLOCATE it uses words which as far as I can see are neither standard nor defined. Specifically write-cell-mem and check-cell-mem which aren't defined.

Also ... It looks to me like ALLOCATE has to store the size somewhere so that FREE can work, since FREE doesn't get passed the size. Should that be clarified?

[r589] 2021-01-07 01:57:20 MitraArdron replies:

example - Relationship to block set

I guess so - so essentially SOURCE (unless its a variable) needs to check BLK and SOURCE-ID - which can only be 0 (for normal); -1 for a string and positive for a file (according to https://forth-standard.org/standard/core/SOURCE-ID and https://forth-standard.org/standard/file/SOURCE-ID (note the latter explicitly points out ambiguity if BLK is non-zero.)

<RANT> One of the challenges I believe with the way this standard is written, is that to implement the words in the standard you have to know specific precise definitions in other words that aren't obviously linked - especially those in extension sets.

[r590] 2021-01-13 08:41:17 PeterKnaggs replies:

requestClarification - write-cell-mem undefined

See F.16 The optional Memory-Allocation word set for the definition of check-cell-mem and other support words.

Yes, we assume ALLOCATE uses a fat pointer, a data structures known only to the compiler is stored in the member immediately proceeding the address returned by ALLOCATE. However, this is only one implementation method, and the committee does not wish to limit implementation to this method only.