,---------------. | Contributions | `---------------´ ,------------------------------------------ | 2021-04-25 19:52:16 agsb wrote: | requestClarification - How many cells can be compared ? Must have any limit ? | see: https://forth-standard.org/standard/string/COMPARE#contribution-193 `------------------------------------------ ,---------. | Replies | `---------´ ,------------------------------------------ | 2021-04-22 02:03:15 MitraArdron replies: | requestClarification - ALLOT in ROMable systems | see: https://forth-standard.org/standard/core/ALLOT#reply-671 `------------------------------------------ @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. ,------------------------------------------ | 2021-04-22 16:39:54 JimPeterson replies: | comment - Throwing past DO/LOOP | see: https://forth-standard.org/standard/exception/THROW#reply-672 `------------------------------------------ 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? ,------------------------------------------ | 2021-04-23 07:44:55 ruv replies: | comment - Throwing past DO/LOOP | see: https://forth-standard.org/standard/exception/THROW#reply-673 `------------------------------------------ > Is there a place, online, to discuss many Forth-related things 1. ForthHub on GitHub platform: 1. [Discussions in the dedicated **discussion** repository](https://github.com/ForthHub/discussion/discussions) 2. Discussions in the [issues of the in the dedicated **discussion** repository](https://github.com/ForthHub/discussion/issues) 3. [Discussions in the **forthhub** team](https://github.com/orgs/ForthHub/teams/forthhub/discussions) 2. [Forth related questions](https://stackoverflow.com/questions/tagged/forth) at StackOverflow 3. [Forth subreddit](https://www.reddit.com/r/Forth/) at Reedit 4. The old `comp.lang.forth` news group, that is available via NNTP and [Google Groups](https://groups.google.com/g/comp.lang.forth) web-interface. 5. Various forums, chats in IRC, Telegram etc. ,------------------------------------------ | 2021-04-23 16:38:42 ruv replies: | proposal - Clarify FIND, more classic approach | see: https://forth-standard.org/proposals/clarify-find-more-classic-approach#reply-674 `------------------------------------------ ### 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](https://forth-standard.org/standard/testsuite#test:core: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](https://forth-standard.org/proposals/clarify-find-more-classic-approach?hideDiff#reply-651) I specified the option A since it seems to have simplest wording. But I think now the option B would be more useful. ,------------------------------------------ | 2021-04-27 14:24:58 ruv replies: | comment - Interpretation semantics | see: https://forth-standard.org/standard/core/COMPILEComma#reply-675 `------------------------------------------ > 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](https://groups.google.com/forum/message/raw?msg=comp.lang.forth/RmsDuen7YkY/xDvW74uzi30J/) (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](https://groups.google.com/g/comp.lang.forth/c/FjyAGu8EoBk) on this in `comp.lang.forth`.