In article <2025Sep22.103934@mips.complang.tuwien.ac.at>,
Anton Ertl wrote:
>albert@spenarnc.xs4all.nl writes:
>>In article <2025Sep22.085631@mips.complang.tuwien.ac.at>,
>>Anton Ertl wrote:
>>
>>>>Only after the word is found, a prefix is handled differently, compare
>>>>immediate words. Such lookup is probably even less effort.
>>>
>>>My understaning is that if the user types
>>>
>>>123456789
>>>
>>>into the text interpreter, your text interpreter will search for
>>>
>>>123456789
>>>12345678
>>>1234567
>>>123456
>>>12345
>>>1234
>>>123
>>>12
>>>1
>>>
>>>and fail at the first 8 attempts, and finally match the ninth, and
>>>only then try to convert the string into a number. By contrast, with
>>>recognizers, every recognizer (including REC-NAME) only has to deal
>>>with the full string, and most other recognizers have simpler and
>>>cheaper checks than REC-NAME.
>>
>>No. 123456789 is looked up in the Forth wordlist, fails, then in the
>>minimum search wordlist.
>>
>>' & ^ 0 1 2 3 4 5 6 7
>>8 9 - + " FORTH
>>
>>1234556789 matches the prefix 1.
>
>How so? Linear search through the wordlist, with prefix matching?
>That's even slower than the approach outlined above (when that
>approach is implemented using hash tables).
I use a simple Forth and there linear search is acceptable for me.
>
>And how does matching "0r" for your roman numerals work, if "0rM"
>matches the prefix "0"?
Normal precedence rules for Forth. 0r is later defined so it is
probed earlier.
>
>>>>Assume we have a PREFIX $ for hex.
>>>>Think of a unix environment, where $ is used for environment variables
>>>>and we want 0x for hex.
>>>>
>>>>NAMESPACE unix \ That is VOCABULARY with a built-in ALSO
>>>>unix DEFINITIONS
>>>>' $ ALIAS 0x
>>>>
>>>>\ Warning: is not unique.
>>>>: $ PARSE-NAME GET-ENV POSTPONE DLITERAL ; IMMEDIATE PREFIX
>>>>
>>>>...
>>>>...
>>>>PREVIOUS DEFINITIONS
>>>>As soon as you kick unix out of the search order, $ is again the
>>>>prefix for hex and 0xCD is no more recognized.
>>>
>>>Gforth has REC-ENV and that is active by default, and there is usually
>>>no reason to eliminate it from the system recognizer sequence. You
>>>write ${HOME}.
>>
>>Does that invalidate the example?
>
>It means that we can mix standard syntax for hex numbers and
>environment variables freely, without having to shadow one with the
>other, or kicking one to be able to use the other.
>
>>>>P.S. GET-ENV leaves a double. Adding POSTPONE DLITERAL makes that
>>>>$XXXX can be used in compilation mode.
>>>
>>>It seems that your approach embraces state-smartness. By contrast,
>>>one benefit of recognizers is that they make it unnecessary to use
>>>words like S" or TO that often are implemented as state-smart words,
>>>or require unconventional mechanisms to avoid that.
>>
>>No I don't. Numbers have always been state-smart, although you
>>won't admit to it.
>
>A state-smart 123 would behave like
>
>: 123
> 123 state @ if postpone literal then ; immediate
>
>By contrast, a normal 123 behaves like
>
>: 123
> 123 ;
>
>Here is a test
>
>: p123 postpone 123 ; : test [ p123 ] ; test .
>
>Let's see how it works (outputs are shown with preceding "\ "):
>
>: 123 \ compiling
> 123 state @ if postpone literal then ; immediate
>\ *terminal*:2:40: warning: defined literal 123 as word ok
>: p123 postpone 123 ; : test [ p123 ] ; test .
>\ *the terminal*:3:39: error: Control structure mismatch
>\ : p123 postpone 123 ; : test [ p123 ] >>>;<<< test
>
>Now with a freshly started system:
>
>: 123 \ compiling
> 123 ;
>\ *terminal*:2:7: warning: defined literal 123 as word ok
>: p123 postpone 123 ; : test [ p123 ] ; test . \ 123 ok
>
>Now with a freshly started system:
>
>: p123 postpone 123 ; : test [ p123 ] ; test . \ 123 ok
>
>The last example uses REC-NUM to recognize 123. It behaves like the
>normal (not state-smart) word 123, showing that numbers are not
>state-smart.
>
>You may say that in a traditional system the last test will not work,
>because POSTPONE does not work with numbers. That's true, but not
>proof of any state-smartness. It just means that we have to look at
>the implementation to decide it. And in the traditional
>implementation the text interpreter decides whether to perform the
>interpretation or compilation semantics of a number, whereas in a
>state-smart word, these two semantics are the same (immediate), and
>the word itself decides when it is run what to do, based on STATE. No
>such thing happens with numbers, so they are not state-smart, not even
>in a traditional system.
You have tried to explain this to me several times, but this is the clearest.
I terminate denotation words with [COMPILE] LITERAL or [COMPILE] DLITERAL.
Suppose I change it to a system where INTERPRET checks whether an
immediate word left something on the stack ( assuming a separate
compilation check) and only in compilation mode adds a LITERAL
(compiles LIT and the number).
In that case denotations doesn't end with [COMPILE] LITERAL/DLITERAL.
Would that be an acceptable implementation?
>
>>In my system you can't postpone numbers, so that cannot lead to
>>problems.
>
>That is certainly a good idea if you have made the mistake of
>embracing state-smartness in your system, but it is another
>disadvantage of your approach compared to recognizers.
To end the controversy, maybe I have to admit I have smart numbers,
but I manage to be ISO-94 compliant.
"AAP"
OK
POSTPONE "AAP"
POSTPONE "AAP" ? ciforth ERROR # 15 : CANNOT FIND WORD TO BE POSTPONED
Maybe not ISO-2012 compliant.
>
>- anton
Groetjes Albert
--
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
