[193] 2021-04-25 19:52:16 agsb wrote:

requestClarification - How many cells can be compared ? Must have any limit ?

[r671] 2021-04-22 02:03:15 MitraArdron replies:

requestClarification - ALLOT in ROMable systems

@TG: Harvard v von Neuman really doesn't capture modern µC's. In a threaded code system such as webForth for example, its irrelevant, as the C compiler takes care of where the code sits, and the dictionary looks like data. What is important is that whether the data is mixed with code or not, there are three kinds of data - ROM/Flash etc, survives reboot and can't be changed; Ram needs initializing, and can be changed; and optionally EEprom or similar that can be changed, survives reboot, but is probably in (very) short supply.

As Anton says, "Rommable systems - are outside the scope of the standard" which in practice means that while it is possible to build a system that is both Forth2012 compliant and rommable, it requires extra non-standard implementation, and a high likelihood that any system level packages are not going to be interoperable.

@TG - the problem with the simplistic memory type specifier like CDATA IDATA is that sometimes this decision happens at the source level, but sometimes it has to be inside the word definition, i.e. VARIABLES always go in Ram and CONSTANTS in Rom, so you'd have to define : VARIABLE ... UDATA CREATE ...; and : CONSTANT ... CDATA CREATE ... ; so that specifying at the source code level is going to be overridden - or at least needs careful standardisation (which won't happen as long as the standards committee thinks its outside scope).

@TG - am I missing something in your example CREATE array 8 ALLOT I think contiguousness just means that I expect those 8 cells to be contiguous, I don't care where that is relative to the definition of array only that executing array gets me a pointer to it.

[r672] 2021-04-22 16:39:54 JimPeterson replies:

comment - Throwing past DO/LOOP

That's quite an interesting technique. Also, I've noticed I was mostly wrong about most of my concerns.

Is there a place, online, to discuss many Forth-related things without distracting the spec. experts with my amateurish ramblings?

[r673] 2021-04-23 07:44:55 ruv replies:

comment - Throwing past DO/LOOP

Is there a place, online, to discuss many Forth-related things

1. ForthHub on GitHub platform:

2. Discussions in the dedicated discussion repository

3. Discussions in the issues of the in the dedicated discussion repository

4. Discussions in the forthhub team

5. Forth related questions at StackOverflow

6. Forth subreddit at Reedit

7. The old comp.lang.forth news group, that is available via NNTP and Google Groups web-interface.

8. Various forums, chats in IRC, Telegram etc.

[r674] 2021-04-23 16:38:42 ruv replies:

proposal - Clarify FIND, more classic approach

Concerning meaning of n in interpretation state

First of all, execution token for a word means the execution token that identifies the execution semantics for this word (regardless whether the standard defines these semantics or not).

Without a doubt, a standard program may rely that for a user defined word, n is 1 if this word is immediate, and n is -1 otherwise

t{ : bar c" foo" find nip ;  : foo ; bar immediate bar -> -1 1 }t

The standard testcase also confirms this point in F.6.1.1550 FIND.

If we extend this rule to all words with default interpretation semantics, then for such a word: if it is immediate, then n shall be 1, otherwise n shall be -1.

So we only have some options for a standard word with non default interpretation semantics (NB: we only consider the case when a word is found in interpretation state). These options are the following:

• A. If the word is implemented as an immediate word, then n is 1, otherwise n is -1.

• B. In any case, n is 1.

• C. n is unspecified among 1 and -1.

Depending on this choice in the specification, a system has different obligations, and a program can have different assumptions.

So if any word (of unknown kind) is found by a program in interpretation state, the program can have the following assumptions from the solely n value:

• in option A: if n is 1, then xt is the execution token for this word and this word is immediate, otherwise n is -1 — no assumptions.

• in option B: if n is -1, then xt is the execution token for this word and this word is not immediate, otherwise n is 1 — no assumptions.

• in option C: regardless of n is 1 or -1 — no assumptions.

What is the most preferable option?

In this version I specified the option A since it seems to have simplest wording. But I think now the option B would be more useful.

[r675] 2021-04-27 14:24:58 ruv replies:

comment - Interpretation semantics

Eventually this requirement (appending semantics in compilation state only) was not included into the normative part of the standard, but some shadows remained.

It should be noted that an official clarification was made in this regard, see TC reply to RFI Q99-027 (the request was prepared by Philip Preston on 1998-10-17).

According to this clarification:

1. It is an ambiguous condition for a program to perform compilation semantics in the interpretation state.
2. It is an ambiguous condition for a program to append semantics to the current definition in the interpretation state.

I have started the new discussion on this in comp.lang.forth.