Digest #289 2024-12-06
Contributions
requestClarification - The search order and compilation word list after a marker execution
The specification for 6.2.1850 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
@AntonErtl wrote in r1038
when you write a state-independent text interpreter, such as a polyForth-style text interpreter, or 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 your colorforth-bw example in Recognizer API. It just works. Note how translators are embedded into recognizers using quotations (in Commit 6c72064).
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
» ?
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.
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 ;
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.
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
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, Swift, Python the prefix «0o
» is used for octal numeric literals.