,---------------.
| Contributions |
`---------------´


,------------------------------------------
| 2024-12-05 09:25:19  ruv  wrote:
| requestClarification - The search order and compilation word list after a marker execution
| see: https://forth-standard.org/standard/core/MARKER#contribution-371
`------------------------------------------
The specification for [6.2.1850 MARKER](https://forth-standard.org/standard/core/MARKER) says:

> Restore all dictionary allocation and search order pointers to the state they had just prior to the definition of _name_.

What does "search order pointers" mean?
Does it mean the search order?  If yes, should the compilation word list be restored?  

If not, would it it be compliant if the system restores the search order and the compilation word list?

> No other contextual information such as numeric base is affected. 

What is a rationale for not restoring the numeric base?



,---------.
| Replies |
`---------´


,------------------------------------------
| 2024-12-04 01:37:18  ruv  replies:
| proposal - minimalistic core API for recognizers
| see: https://forth-standard.org/proposals/minimalistic-core-api-for-recognizers#reply-1390
`------------------------------------------
@AntonErtl wrote in [r1038](https://forth-standard.org/proposals/minimalistic-core-api-for-recognizers#reply-1038)

> when you write a state-independent text interpreter, such as a polyForth-style text interpreter, or [colorforth-bw](https://www.complang.tuwien.ac.at/forth/colorforth-bw), you would have to set `state` before executing the translators, which is perverse.

It is not more perverse than repeating «`_`»,  «`]`», or «`[`» before **each** lexeme in a program ;)

In general, when the Recognizer word set is provided, the Forth text interpreter itself knows nothing about `STATE`.  If you write a state-independent text interpreter, your recognizers should provide state-independent token translators. And you have not to set `state` at all. I [rewrote](https://github.com/ForthHub/fep-recognizer/blob/master/implementation/example/recognize-colorforth-bw.fth) your colorforth-bw example in Recognizer API. It just works. Note how translators are embedded into recognizers using quotations (in [Commit 6c72064](https://github.com/ForthHub/fep-recognizer/commit/6c720642eee4e16697756d9b8a6a87208a8b801f)).


> And in the case of colorforth-bw, again there is no standard way to set `state` to get the translator to perform xt-post.

In this approach, why do you need to write «`[postpone _foo`» instead of «`]foo`» ?



,------------------------------------------
| 2024-12-04 11:59:41  BerndPaysan  replies:
| proposal - Known undefined word XLERB
| see: https://forth-standard.org/proposals/known-undefined-word-xlerb#reply-1391
`------------------------------------------
The research of established practice showed that `XLERB` is already used for this purpose, while `NOTAWORD` isn't.  The whole point of `XLERB` is that nobody other than the cat when walking over the keyboard will accidentally produce such a word.  `NOTAWORD` could have a function like checking if a word is too short, too long, or contains non-graphical letters and in that case throw the appropriate error code.


,------------------------------------------
| 2024-12-04 14:06:02  alextangent  replies:
| proposal - Octal prefix
| see: https://forth-standard.org/proposals/octal-prefix#reply-1392
`------------------------------------------
Here's a suggestion. Use & as a prefix. 

The nice feature of using & is that it is part of the ASCII sequence #$%& and lookup for the prefix is one of the values between # and & inclusive (decimal 35 thru 38). I'm not aware of any other formal or informal use of &.

```
\ Can be used to force number recognition in any base
\ $ -- hex prefix
\ # -- decimal
\ % -- binary
\ & -- octal
\                #     $     %    \ &    \ '
create num-bases 10 c, 16 c, 2 c, \ 8 c, \ 0 c,

: num-base! ( addr u -- addr' u' ) 
\ given a string, if prefixed set BASE and return the rest of the string
\ otherwise return the input string
    over c@ '#' - dup 4 u< if
      >r 1 /string r>
      num-bases + c@ base!
    else drop then ;
```




,------------------------------------------
| 2024-12-04 14:19:10  alextangent  replies:
| proposal - Octal prefix
| see: https://forth-standard.org/proposals/octal-prefix#reply-1393
`------------------------------------------
Ah, I just saw Anton's references to prior art with &. I will continue to use it on my system, but my use of it is mainly in the assembler & disassembler where the x86 instruction set uses many octal encodings. I use @ for indirect references (eg @name is the address of name).  Since I use recognizers, the & and @ prefixes could be switched in and out easily, Notwithstanding that, I wouldn't standardize any octal prefix; it's a lot of potential pain for not a lot of gain. Use recognizers if that's what you need.  


,------------------------------------------
| 2024-12-04 17:05:22  achowe  replies:
| proposal - Known undefined word XLERB
| see: https://forth-standard.org/proposals/known-undefined-word-xlerb#reply-1394
`------------------------------------------
FYI It appears that a domain name exists...
```
elf$ dig +short a XLERB.com
78.46.71.148
elf$ dig +short a XLERB.org
192.64.119.74
elf$ dig +short a XLERB.net
173.255.243.151
```



,------------------------------------------
| 2024-12-04 17:36:50  ruv  replies:
| proposal - Octal prefix
| see: https://forth-standard.org/proposals/octal-prefix#reply-1395
`------------------------------------------
> Notwithstanding that, I wouldn't standardize any octal prefix; it's a lot of potential pain for not a lot of gain. Use recognizers if that's what you need. 

Agreed!  If an octal prefix is needed, it can be easily added using the Recognizer API so that it only applies in limited lexical scopes.

By the way, in JavaScript, Go, [Rust](https://doc.rust-lang.org/rust-by-example/primitives/literals.html), Swift, Python the prefix «`0o`» is used for octal numeric literals.