,---------------. | Contributions | `---------------´ ,------------------------------------------ | 2020-08-28 11:29:47 ruv wrote: | requestClarification - Get execution semantics from nt | see: https://forth-standard.org/standard/search#contribution-150 `------------------------------------------ How can we conclude from _nt_, do **identifiable** execution semantics are defined for the corresponding definition? And how to get the corresponding _xt_, if any? By "identifiable" I mean that these semantics can be identified by an execution token _xt_ — to exclude the cases of the words like `EXIT`, `>R`, etc, that have only nominal execution semantics (see also news:[r2u5p3$n4p$1@dont-email.me](https://groups.google.com/forum/message/raw?msg=comp.lang.forth/1SDLacsZprk/R5gglBZyAwAJ)). ,---------. | Replies | `---------´ ,------------------------------------------ | 2020-08-23 13:05:06 KrishnaMyneni replies: | proposal - OPTIONAL IEEE 754 BINARY FLOATING-POINT WORD SET | see: https://forth-standard.org/proposals/optional-ieee-754-binary-floating-point-word-set#reply-420 `------------------------------------------ ## Author: Krishna Myneni ## Change Log: 2020-08-18 v 0.0.1 first draft posted on comp.lang.forth
2020-08-21 v 0.0.2 revised to introduce essential word for defining double-precision IEEE floating point value.
2020-08-22 v 0.0.3 fix code formatting and add references
2020-08-23 v 0.0.4 fix reference
## Problem: The IEEE 754-2008 standard for floating point arithmetic [1] provides numerous advantages for those who write numerical floating point programs [2], including standardized floating point number formats which have been widely adopted for several decades, as well as a significantly simpler approach to dealing with exceptions in floating point arithmetic. Although significant parts of an optional IEEE floating point word set for Forth have been developed as RfD's since 2009, the proposal(s) [3] have languished now for 11 years without any progress towards including their features within a standard. This RfD takes the view that the lack of progress is primarily a result of two factors: 1. the complexity of the problem in specifying even a partially complete solution for support of the features IEEE 754-2008 standard, particularly with the setup and enabling of traps for floating point arithmetic exceptions, and 2. the relatively low use of floating point arithmetic, and specifically of programs which require more than simple floating point numerical calculations, within the Forth user community.

Even in language standards which have adopted many of the IEEE 754 arithmetic features, support is often incomplete. One such example is the C99 standard, which specifies extensions for features such as setting the rounding modes and masking floating point exceptions, but does not specify a way to enable and disable floating point exception traps.

Several Forth systems [4] have already extended their floating point capabilities to include IEEE 754 features such as special binary values representing signed infinity (+/-INF) and "not a number" (NAN) values, with possibly different names.

## Solution:

Instead of a more or less comprehensive proposal, specifying words to provide most of the functionality within the IEEE 754 standard, we propose the formal inclusion within the standard of the "optional IEEE 754 binary floating-point word set", initially containing a minimal set of words to allow creating IEEE binary floating point values with bit-level precision. Further functionality provided by the IEEE 754-2008 standard may be added by subsequent proposals.

In this proposal, in addition to the inclusion of the "optional IEEE 754 binary floating-point word set", also adding the word MAKE-IEEE-DFLOAT which permits the creation of any recognized double precision floating point value. It will allow definition of special IEEE 754 floating point values which are returned by default upon certain arithmetic exceptions (+/-INF, NAN), and are useful for detecting an arithmetic exception. The IEEE 754 standard also provides other mechanisms for detecting and dealing with floating point arithmetic exceptions.

Subsequent proposals can incrementally add IEEE 754-2008 or IEEE 754-2019 functionality to the standard optional word set. For example, another proposal can add standardized named constants for special binary values returned upon arithmetic exceptions. Another proposal may formally update the specifications for existing floating point arithmetic words for consistency with the IEEE 754 standard, and yet another proposal may add words for exception detection by providing access to the exception flags of the floating point unit. Such changes may be introduced individually so that the problem of providing consistent floating point arithmetic consistent with the IEEE 754 standard can be tackled in pieces rather than all at once. Given the substantial amount of work already done towards such an optional word set [3], the problem can be reduced to identifying groups of words which may be added separately to provide enhanced capabilities.

The adoption of an "optional IEEE 754 binary floating-point word set" into the Forth 20xx standard, initially with minimal provisions, will be immediately useful for practitioners of numerical floating-point computation in Forth. The proposed addition to the new word set is MAKE-IEEE-DFLOAT ( F: -- r ) ( signbit udfraction uexp -- error ) which will return an IEEE 754 double precision floating point value from the specified bit fields for the sign, binary fraction, and exponent. It will also validate the binary fraction and exponent fields for consistency with the IEEE binary format and return a error value on the data stack, 0 for no error and non-zero values to indicate the type of failure. The least significant bit of the *signbit* value represents the sign of the floating point value (0 is positive, 1 is negative), the lower 32-bits of each cell value of *udfraction* are concatenated to provide the binary fraction bits of the mantissa, and *uexp* provides the binary representation of the exponent.

## Typical use: HEX 0 54442D18 921FB 1 MAKE-IEEE-DFLOAT fconstant pi ## Proposal:

1. Adopt the Optional IEEE 754 binary floating point word set into the Forth 20xx standard.
2. The new word set will provide the word MAKE-IEEE-DFLOAT with the specifications given above.

## Reference implementation: The reference implementation is specific to a 32-bit, little-endian Forth system. HEX \ Make an IEEE 754 double precision floating point value from \ the specified bits for the sign, binary fraction, and exponent. \ Return the fp value and error code with the following meaning: \ 0 no error \ 1 exponent out of range \ 2 fraction out of range fvariable temp : MAKE-IEEE-DFLOAT ( signbit udfraction uexp -- r nerror ) dup 800 u< invert IF 2drop 2drop F=ZERO 1 EXIT THEN 14 lshift 3 pick 1F lshift or >r dup 100000 u< invert IF r> 2drop 2drop F=ZERO 2 EXIT THEN r> or [ temp cell+ ] literal ! temp ! drop temp df@ 0 ; ## Testing: (Optional) ## References 1. IEEE, *754-2008 - IEEE Standard for Floating-Point Arithmetic - Redline*, (2008). 2. W. Kahan, *Lecture Notes on the Status of IEEE Standard 754 for Binary Floating-Point Arithmetic*, (1997). 3. D. N. Williams, *Proposal for an Optional IEEE 754 Binary Floating-Point Word Set*, v 0.5.4, (2009); Also, see older and more recent versions of this draft proposal and another proposal for supporting IEEE 754 exceptions and exception handling at . 4. Based on discussions in comp.lang.forth during August 2020, the following systems appear to be able to output IEEE 754 values for signed INF: iForth gforth, lxf, kForth-32. Only iForth appears to support an intrinsic definition of fp values for +/-INF. ,------------------------------------------ | 2020-08-23 14:52:06 StephenPelc replies: | proposal - OPTIONAL IEEE 754 BINARY FLOATING-POINT WORD SET | see: https://forth-standard.org/proposals/optional-ieee-754-binary-floating-point-word-set#reply-421 `------------------------------------------ # Re: MAKE-IEEE-DFLOAT ( F: -- r ) ( signbit udfraction uexp -- error ) I fully support the need for such a word (and its reciprocal) but having covered several IEEE handling CPUs, the natural way to look at an IEEE value is
sign exp fraction
and this also applies for non-IEEE values as used for some embedded systems without FPUs. I also worry about the error return. What do Nan and Inf result in. If there is no error, then +/-Nan is surely the right thing to return, and the error code can disappear, leaving no problems with ambiguous conditions or error codes. The TC voted some years back that error codes should be unique so that they can be used as THROW codes. The reciprocal operation is also useful:
FLOAT>PARTS ( F: -- ; -- sign exp fraction ) ,------------------------------------------ | 2020-08-23 20:23:12 StephenPelc replies: | proposal - 2020 Forth Standards meeting agenda | see: https://forth-standard.org/proposals/2020-forth-standards-meeting-agenda#reply-422 `------------------------------------------ # 2020 Forth Standards Meeting ## 1-3 Sept 2020, Online We expect to be using BigBlueButton or Zoom or Webex or some such. If you want to rant or rave about online meeting tools, it's outside the scope of this document. For reasonable discussion, contact Stephen Pelc, stephen@mpeforth.com ## Schedule The standards meeting will be Tuesday-Thursday from 2:30 pm to 6:30 pm CEST with a short bio-break at 4:30. This solution fits with at least one committee member who doesn't do Mondays! ## Participants ## Review of Procedures 1. Covid consequences 2. Brexit consequences 3. Payment for services/licences ## Reports 1. Chair 2. Editor 3. Technical 4. Treasurer ## Review of Proposals and Activities 1. Recognisers
Stay as experimental proposal?
Separate POSTPONE action?
Impact of dot parser on POSTPONE? 2. Multi-tasking from APH 3. Ambiguous condition and IMMEDIATE
TC answer by Bernd, 2019-09-12 15:19:24
Move from RUV, any further action? 4. CS-DROP from UH
say orig and dest must be same size
Go to vote? 5. Case insensitivity
ASCII case insensitivity only.
Go to vote? 6. Remove the “rules of FIND” (BP)
Locals word set?
Go to vote? 7. Reference implementation of SYNONYM (AE, RUV)
Broken reference implementation.
New reference implementation. 8. VOCABULARY (UH) 9. Unfindable definitions (RUV) 10. Case sensitivity in [IF] and friends. 11. FIND 12. FIND-NAME 13. License (JK, RUV) 14. String, EPLACES (RUV)
Error if macro does not exist during compilation? 15. Why RECURSE is needed (BI) Pick a TC answer. 16. Input values other than true and false [IF]
Pick flag as z/nz, vote, TC response 17. sample implementation that can also be interpreted (MAX)
Adopt RUV's response as TC answer. 18. Better wording for Colon (RUV) 19. NAME>INTERPRET wording (RUV) 20. The parts of execution semantics and the calling definition (RUV) 21. Recognizer RfD rephrase 2020 (UH)
Move to recogniser workshop 22. "(" typo in a testcase (RUV)
Assign to editor 23. Wording: declare undefined interpretation semantics for locals (RUV)
Remove ambiguous conditions 24. Word set of S>D word (RUV) Leave as is? 25. Same name token for different words (RUV) 26. Recognizer for locals (RUV) 27. There is error in testing SM/REM (MB)
Pass to editor 28. Defer Implementation (Tolich) 29. Recogniser (BP)
Move to recogniser workshop. 30. Does wording imply that if you SYNONYM a word with the same name (JN) 31. What happens when parse reaches the end of the parse area? (JN) 32. TEST instead of TEAT in F.1 para 2 (JN)
Pass to editor ## Workshop Topics Workshops are topics for discussion outside the formal meeting. 1. Future Document Format 2. Stack comments
stack comments should be parseable
Stack naming S: D: F: N: R:
stack effect notation
stack effect conventions 3. Test suites
Philosophy
J Hayes sequencing
G Jackson suite 4. Workshop reports ## Consideration of proposals + CfV votes ## Matters arising ## Any other business ## Date of next meeting ,------------------------------------------ | 2020-08-24 23:36:24 KrishnaMyneni replies: | proposal - OPTIONAL IEEE 754 BINARY FLOATING-POINT WORD SET | see: https://forth-standard.org/proposals/optional-ieee-754-binary-floating-point-word-set#reply-423 `------------------------------------------ Changing the order of the inputs on the data stack for MAKE-IEEE-DFLOAT to sign uexp udfraction is fine if it proves to be more convenient. I have no objection to such a change.

With respect to FLOAT>PARTS , I anticipate the following words will be needed to fetch the individual binary fields of a floating point value: FSIGNBIT (contained in DNW's IEEEE 754 proposal v0.5.5, section 8.7) FEXPONENT FFRACTION While MAKE-IEEE-DFLOAT assembles a specifc type of IEEE binary float format (double precision), a generic word such as FLOAT>PARTS should work with the default binary format used by the system, i.e. the same format of the values stored on the floating point stack. The above words, FSIGNBIT FEXPONENT FFRACTION should also apply to the default floating point format. I have not been included in this proposal, but they probably should be included.


The considerations above raises the question of whether or not MAKE-IEEE-SFLOAT should also be included. Are there Forth systems with a floating point stack for single precision floats?


,------------------------------------------ | 2020-08-24 23:38:37 KrishnaMyneni replies: | proposal - OPTIONAL IEEE 754 BINARY FLOATING-POINT WORD SET | see: https://forth-standard.org/proposals/optional-ieee-754-binary-floating-point-word-set#reply-424 `------------------------------------------ Sorry, I accidentally changed the status to Retired. This proposal is not retired. ,------------------------------------------ | 2020-08-24 23:42:43 KrishnaMyneni replies: | proposal - OPTIONAL IEEE 754 BINARY FLOATING-POINT WORD SET | see: https://forth-standard.org/proposals/optional-ieee-754-binary-floating-point-word-set#reply-425 `------------------------------------------ To answer the question of whether NaNs should return an error code from MAKE-IEEE-DFLOAT, my thinking is that all IEEE 754 special values should be considered valid. This allows the use of MAKE-IEEE-DFLOAT for defining named constants for the special values. If the TC wants the error codes to be reserved throw codes, that's fine. ,------------------------------------------ | 2020-08-25 09:01:33 AntonErtl replies: | comment - Recognizer for locals | see: https://forth-standard.org/standard/locals#reply-426 `------------------------------------------ The existence of the sentence "The system need not maintain ..." only makes sense if "they" refers to the locals. The other dictionary entries can be found with the normal dictionary searching processes anyway, so the sentence would be redundant if "they" referred to the other dictionary entries. Two arguments for requiring that FIND-NAME/FIND find locals: 1. FIND-NAME/FIND are "normal dictionary searching processes", so these words should find the locals according to that sentence. 2. The intent of the Forth-94 committee (and also my intent when proposing FIND-NAME) was that it is possible to write a user-defined text interpreter, as outlined in [the rationale for COMPILE,](https://forth-standard.org/standard/rationale#rat:core:COMPILE,). There is no other standard way to find locals, so FIND and FIND-NAME should include this functionality. An argument against: 3. We did not mention locals in the specifications of FIND and FIND-NAME. But given the intent, that was an oversight, certainly on my part. Looking at what existing systems do, I wrote the small test : x c" fluffystunk" ; : foo locals| fluffystunk | [ x find cr .s 2drop ] ; In VFX and Gforth, FIND finds fluffystunk; in SwiftForth, iForth, and lxf, FIND does not. Apparently this has not been an issue for 26 years, so apparently nobody has used a user-defined text interpreter to process a program using locals on SwiftForth, iForth, or lxf; nor has anybody written a program that relies on FIND not finding locals, and let it run on VFX or Gforth. Still, I think that the standard should nail this issue down. ,------------------------------------------ | 2020-08-26 14:41:54 ruv replies: | proposal - find-name | see: https://forth-standard.org/proposals/find-name#reply-427 `------------------------------------------ > would an implementation that treated name tokens and execution tokens as being the same thing cause any problems? A Forth system can be implemented in such a way that _nt_ and _xt_ are the same thing without any problems with compliance to the standard. Some operation just would be a bit slower. > `NAME>INTERPRET` and `NAME>COMPILE` would still be in the wordlist but do nothing to the token. In such case, `NAME>COMPILE` for the FILE `S"` word cannot return xt of `EXECUTE` at the top. It should return xt of some special `EXECUTE-COMPILING` word. ``` : token-compile-for-s" ( -- x xt ) nt-of-s" ['] execute-compiling ; ``` Another variant is that `NAME>COMPILE` for `S"` returns another nt and xt of `EXECUTE`. ``` : token-compile-for-s" ( -- x xt ) nt-of-s"-compiling ['] execute ; ``` > If you don't implement SYNONYM Also, I don't see any problem to implement [`SYNONYM`](/standard/tools/SYNONYM). ,------------------------------------------ | 2020-08-26 16:36:31 ruv replies: | requestClarification - What happens when parse reaches the end of the parse area and the parse delimiter was not found? | see: https://forth-standard.org/standard/core/PARSE#reply-428 `------------------------------------------ > When loading from a file, my Forth's SOURCE returns the start address of the buffer the file was loaded into and the length of the entire file. If you want to be standard compliant, just use another name for your flavor, and provide `SOURCE` with standard behavior. Ditto for other standard words. The Forth text interpreter is not obligated to use all these standard words, they can be provided just for programs. You can even implement `SOURCE` in lazy evaluated manner (with memorization): that is, it calculates the length on the first call after each pass of the line terminator. Your `REFILL` can just adjust your pointer in the entire file. `>IN` is harder for virtualization (it would be better to have a setter and getter). When `>IN` was used, `PARSE`, `PARSE-NAME` and `WORD` should check changes of `>IN` value. OTOH, the corresponding overhead will take place in some programs only, and not in the system itself. > Also, in my Forth, if PARSE ends on a line terminator, >IN will have the offset of the line terminator. In other standard Forths, that would technically be the length of the current input buffer and not be pointing to a valid character. A standard program cannot read a character beyond the input buffer. So it doesn't matter is it a valid character or not. ,------------------------------------------ | 2020-08-26 23:57:01 JamesNorris replies: | requestClarification - What happens when parse reaches the end of the parse area and the parse delimiter was not found? | see: https://forth-standard.org/standard/core/PARSE#reply-429 `------------------------------------------ I did some more reading and found that the interpreter section refers you to QUIT, and if you look up all the terms, a line is defined as a sequence of characters followed by a line terminator or implied line terminator. My forth doesn't implement the file extension word set so I didn't read that until today. I do something different. I don't see why this is important to do... or if I do the work arounds above, why they are needed. The only thing I can think of is older Forths use preallocated memory regions to hold input. My Forth has dynamic memory allocation so I am not restricted by that. When I did my Forth I was thinking someone someday may be working on a terminal device and have something more complicated where they can put line terminators and other characters into the input stream. If you are using an operating system function to do ACCEPT like I am, I thought it would be a good idea to not assume that operating system would always follow the rules. I suppose you could pre-parse the 'line' returned from the operating system as if it were a file to pull out each line, but why? Why is it so important that SOURCE refer to a line and >IN be the offset from the beginning of a line? Who needs this behavior? Isn't enough that SOURCE and >IN refer to the current parsing position? In reality this is a restriction that line terminators can't be in the input buffer. In any case, I think don't my Forth will be following this part of the standard. It's just kind of a bummer. I thought I did a good job of reading the standard and following everything, but it turns out I missed something. ,------------------------------------------ | 2020-08-27 11:09:16 ruv replies: | comment - Recognizer for locals | see: https://forth-standard.org/standard/locals#reply-430 `------------------------------------------ > Two arguments for requiring that FIND-NAME/FIND find locals As I can see, we have some arguments not for requiring, but for **allowing**. 1. I agree that "they" refers to identifiers of the locals. But it seems to me, "as long as they can be found" means that the corresponding statement is only applicable when locals "can be found by normal dictionary searching processes". It does not require that they **should** be found by "normal dictionary searching processes". OTOH, what is "normal dictionary searching processes"? And do we have non normal dictionary searching processes? This wording too fuzzy to produce strong arguments. 2. Actually, there is no any standard way to find locals, despite the intention. So, I suggest to introduce such a way via recognizer. Concerning FIND. I think, when the Search-Order word set is provided, we can allow FIND-NAME to find locals only via the search order (i.e., when they are implemented as some special word list that is appended to the top of search order). Otherwise, FIND-NAME cannot be implemented via [TRAVARSE-WORDLIST](/standard/tools/TRAVERSE-WORDLIST). Also, some existent implementation become nonstandard. So, we should allow, but should not require this approach. I think, we should provide a recognizer for locals, that will works in any case. ,------------------------------------------ | 2020-08-27 17:15:57 ruv replies: | comment - Recognizer for locals | see: https://forth-standard.org/standard/locals#reply-431 `------------------------------------------ Correction: Otherwise (i.e., if `FIND-NAME` is required to search locals and allowed to do it beyond the search order), the function of `FIND-NAME` cannot be implemented via `GET-ORDER` and `TRAVARSE-WORDLIST`. ,------------------------------------------ | 2020-08-27 18:50:37 AntonErtl replies: | proposal - Case insensitivity | see: https://forth-standard.org/proposals/case-insensitivity#reply-432 `------------------------------------------ ## Effect on Performance I have measured this in <<2002Nov22.175007@a0.complang.tuwien.ac.at>>: >Gforth stores words in the original case, and uses a case-insensitive >compare. I did some timings in Gforth on an Athlon: > >1) searching for "execute" in a (case-sensitive) wordlist that >contains only "execute": 2009 cycles > >2) searching for "execute" in a (case-insensitive) wordlist that >contains only "execute": 2042 cycles > >3) searching for "execute" in forth-wordlist (case-insensitive): 2117 >cycles. ,------------------------------------------ | 2020-08-28 08:00:31 ruv replies: | proposal - Clarify FIND, more classic approach | see: https://forth-standard.org/proposals/clarify-find-more-classic-approach#reply-433 `------------------------------------------ It is an alternative proposal to the [one from Anton](https://forth-standard.org/proposals/clarify-find#reply-165). ### Problem 1. The existing specification of FIND is unclear how the returned xt is connected with interpretation and compilation semantics for the corresponding word. 2. In some popular Forth systems n=1 does not mean that the word is immediate. ### Solution Use the new wording in the specification for FIND. Keep the original immediacy notion, but use another (more loose) wording for meaning of _n_ in compilation state. The new wording allows to implement the words with undefined execution semantics as "dual-xt" words, and still allows (as it was before) to implement them as immediate STATE-dependent words. Also it allows to have the special definitions to compile the words with undefined interpretation semantics and defined execution semantics (like `EXIT`), and return proper values for them from `FIND`. #### Some differences to the Anton's proposal More accurate wordings that are closer to the language of standard. Use "default interpretation semantics" criteria instead of referring to POSTPONE (item 3 in my [comment](https://forth-standard.org/proposals/clarify-find#reply-294)). Allow to implement words without interpretation semantics (e.g., IF) as immediate STATE-dependent words (as it was before). Do specify what _n_ means in all possible cases (news:[qnko0l$jk2$1@dont-email.me](http://al.howardknight.net/?ID=159859705600)). Don't change 4.1.2. since FIND cannot and doesn't return xt for a definition with not default interpretation semantics. The new specification guarantees that a user-defined text interpreter can interpret any word that is found by FIND. Also, 4.1.2 should be updated independently by itself. Nowadays many Forth systems don't use FIND by themselves but provide it for the old-fashion programs only. There is no much sense to restrict the implementation options of the modern Forth systems for the sake of the outdated approach. I think the modern Forth systems will tend to use Recognizer/Resolver approach for the special syntaxes and special words. ### Proposal Replace the text in the specification of FIND with the following. --- __FIND__ _( c-addr -- c-addr 0 | xt n )_ Find the definition _name_ whose name matches the counted string at _c-addr_. If the definition is not found, return _c-addr_ and zero. Otherwise the definition is found, return _xt_ and _n_. If _name_ has default interpretation semantics, _xt_ is the execution token for _name_, and _n_ is 1 if _name_ is immediate word, -1 otherwise. The returned values are the same regardless whether the definition is found in interpretation state or in compilation state. If _name_ has other than default interpretation semantics, _xt_ is the execution token for an unspecified implementation-dependent definition, and _n_ is 1 or -1, and the following conditions are met. 1. When the definition is found in compilation state: if _n_ is 1, performing _xt_ in compilation state performs the compilation semantics for _name_, otherwise _n_ is -1, and appending the execution semantics identified by _xt_ to the current definition performs the compilation semantics for _name_. 2. When the definition is found in interpretation state: if _n_ is 1, _xt_ and _n_ are the same when the definition is found in compilation state, otherwise _n_ is -1, and both _xt_ and _n_ may be different when the definition is found in compilation state; performing _xt_ in interpretation state performs the interpretation semantics for _name_. 3. The definition may be not found in interpretation state but found in compilation state, and vise versa. Also a definition may be not found at all. An ambiguous condition exists if _xt_ is performed in the conditions that are not met the conditions specified above. ----- "Performing _xt_" means performing the execution semantics identified by the execution token _xt_. A definition has **default interpretation semantics** if and only if the "Interpretation:" section is absent in the corresponding glossary entry, and the "Execution:" section is present (see also [3.4.3.1](https://forth-standard.org/standard/usage#subsubsection.3.4.3.1)). Default interpretation semantics for a definition is to perform its executin semantics in interpretation state (see also [3.4.3.2](https://forth-standard.org/standard/usage#subsubsection.3.4.3.2)). If interpretation semantics are undefined for a definition, a Forth system is allowed to provide implementation-defined interpretation semantics for this definition (see [A.3.4.3.2](https://forth-standard.org/standard/rationale#paragraph.A.3.4.3.2)). In such case, when the definition is found in interpretation state, performing the returned _xt_ in interpretation state performs the implementation-defined interpretation semantics for _name_. A program is allowed to apply `FIND` to any string. A definition may be not found by `FIND` even if a Forth system provides interpretation or compilation semantics for the corresponding name (for example, in the case of locals). ,------------------------------------------ | 2020-08-28 12:29:27 ruv replies: | proposal - Recognizer | see: https://forth-standard.org/proposals/recognizer#reply-434 `------------------------------------------ > There are a number of discussions going on elsewhere, and I want to make sure the discussion is going to be here. There are too many questions to discuss all of them on a single page. I opened several [issues](https://github.com/ForthHub/fep-recognizer/issues?q=is%3Aissue+label%3Av4-review) on the subject of review API v4. Please check. Some notable of them: - side effects are not acceptable ([Issue #7](https://github.com/ForthHub/fep-recognizer/issues/7)) - arguments against VALUE in API ([Issue #5](https://github.com/ForthHub/fep-recognizer/issues/5)) - accessors are not needed ([Issue #6](https://github.com/ForthHub/fep-recognizer/issues/6)) - new arguments concerning "unrecognized vs zero" ([Issue #4](https://github.com/ForthHub/fep-recognizer/issues/4)) - choosing better names ([Issue #3](https://github.com/ForthHub/fep-recognizer/issues/3)) I suggest the following [road map](https://github.com/ForthHub/fep-recognizer/issues/1): 1. Terms definitions and data types 2. A minimal essential part 3. Choose among the different approaches (e.g., I suggest to discard both postponing and reproducing actions in the public API). 4. Choose solutions for some problems 5. Choose names ,------------------------------------------ | 2020-08-28 13:08:28 ruv replies: | proposal - Nestable Recognizer Sequences | see: https://forth-standard.org/proposals/nestable-recognizer-sequences#reply-435 `------------------------------------------ I strongly support this approach: to switch the recognizer that the Forth text interpreter uses, we pass the xt of another recognizer to the system. But, as I [said](https://github.com/ForthHub/fep-recognizer/issues/5) before, it's better to have the separate getter and setter instead of the single value that is changed via `TO`. `GET-REC-SEQUENCE` and Co. can comprise a totally separate proposal. And it is worth to extract them into a separate proposal to make the basic proposal less in size and number of conflicts. ,------------------------------------------ | 2020-08-28 15:12:13 ruv replies: | proposal - Same name token for different words | see: https://forth-standard.org/proposals/same-name-token-for-different-words#reply-436 `------------------------------------------ Two definitions can have the different execution semantics when the interpretation semantics for them are the same and the compilation semantics are the same [1]. So, we should mention the same execution semantics too: **The different words may have the same name token if their names are identical, the actual interpretation semantics for them are equivalent, the actual compilation semantics for them are equivalent, and if the execution semantics defined for one of them, the execution semantics for another one are equivalent to the first one.** Or, in a shorter variant: **The different words may have the same name token if their are synonyms having identical names.** The idea is that if two words have the same name (what about case-sensitivity?), and they behavior indistinguishable, they may have the same _nt_. OTOH, I don't insist that we should namely allow the same _nt_ for the different words. But I think, we should either explicitly allow, or explicitly prohibit the same _nt_. ----- [1] [Example](https://forth-standard.org/standard/core/Tick#reply-332): ``` : foo 0= ; : bar ['] 0= state @ if compile, else execute then ; immediate \ testcase that shows the different execution semantics : [e] execute ; immediate 0 ' foo ] [e] [ . \ prints -1 0 ' bar ] [e] [ . \ prints 0 (or even throws an exception) ``` I remember that by Anton's view (in the last year at least), the interpretation semantics for them are different, and the compilation semantics for them are different too. But it seems, this view even isn't supported by the authors of the original [reference implementation](http://www.forth200x.org/synonym.html) for [SYNONYM](https://forth-standard.org/standard/tools/SYNONYM).