[340] 2024-05-29 20:11:10 TKurtBond wrote:

requestClarification - Data space seems to be used invonsistently when comparing the definitions of "character string" and "data space".

The definition of "character string" says "Data space that is associated with a sequence of consecutive character-aligned addresses." However, the definition of "data space" says "The logical area of the dictionary that can be accessed." Character strings don't have to be part of the dictionary: for instance, when they created using ALLOCATE, contradicting the definition of "data space".

Is "data space" supposed to be any arbitrary memory, or just the memory in the dictionary? If the later, is there a better to use in the definition of "character string"?

[r1220] 2024-05-14 06:26:27 AntonErtl replies:

requestClarification - Is it possible to eliminate the need for `UNLOOP`?

How would your automatic approach correctly implement stuff like:

: foo
  >r
  ... ?do
    >r ?do
      ... if
        unloop r> unloop r> exit then
      ...
    loop
    ... r> ...
  loop
  ... r> ... ;

if unloop is a noop.

Concerning locals: The standard puts a lot of restrictions on locals usage in order to, (among other things) eliminate the need for something like unlocals, e.g., a standard program must not use multiple locals definitions nor define locals inside a control structure. Gforth does not restrict its programmers that much, but pays for it by having to maintain a separate locals stack.

[r1221] 2024-05-14 11:11:18 ruv replies:

requestClarification - Is it possible to eliminate the need for `UNLOOP`?

Anton, thank you for your example. You are right, in this standard-compliant case unloop cannot be eliminated, without additional restrictions on the do-loop implementation (to not use r-stack for loop-sys).

[r1222] 2024-05-24 15:21:35 bfox9900 replies:

referenceImplementation - Possible Reference Implementation

Here is a version for systems without locals. Not sure it would be faster with all the stack manipulation but it works.

: SEARCH ( caddr1 u1 caddr2 u2 -- caddr3 u3 flag) BEGIN DUP WHILE 2OVER 2OVER DROP OVER COMPARE WHILE 1 /STRING
REPEAT 2NIP TRUE EXIT THEN 2NIP FALSE ;

[r1223] 2024-05-30 11:49:16 AntonErtl replies:

requestClarification - Data space seems to be used invonsistently when comparing the definitions of "character string" and "data space".

These definitions were written for the standard without any extension wordsets. However, in that case the memory allocation wordset should redefine "data space" (or "character string"). Data space has come up several times as being confusing, so maybe a better definition is in order.

Concerning "character string", another issue is the strings returned by the run-time semantics of s", s\", sliteral, and likewise for the counted string returned by the run-time semantics of c". Typical systems will return strings that reside in what is arguably code space (or arguably data space). Maybe we should define "character string" in a way that makes such arguing unnecessary.

[r1224] 2024-05-30 17:31:47 ruv replies:

requestClarification - Data space seems to be used invonsistently when comparing the definitions of "character string" and "data space".

The definition of "character string" says "Data space that is associated with a sequence of consecutive character-aligned addresses."

I think, it should say "A data space region that is associated with a sequence of consecutive character-aligned addresses." It's the same problem that was fixed for the "data field" term.

However, the definition of "data space" says "The logical area of the dictionary that can be accessed." Character strings don't have to be part of the dictionary: for instance, when they created using ALLOCATE, contradicting the definition of "data space".

I agree that some definitions can be be made better.

But conceptually, why not? Data space is not a single memory region, but a set of memory regions. See my explanation in the post "Data space notion in Forth Standard".