On 2024-07-31 21:33, Anton Ertl wrote:
Maybe those who like this kind of
TO implementation will make a proposal that means that you cannot
POSTPONE TO with a user-defined POSTPONE.
How?
Disallow obtaining the name token for "to"? That's a very weak
approach.
It seems, it is possible to test whether "to" is parsing, and if not, >redefine it to provide a parsing "to" in a standard system.
I came up with the following test:
0 value _v1 immediate
0 value _v2
: test(to)
1 1
[ 1 ] to _v1 _v2 [ ( 1 | 1 0 ) ?dup 2drop ]
( 1 | 1 0 ) ?dup 2drop
;
test(to) _v2 [if]
.( ["to" is not a parsing word] )
[else]
.( ["to" is a parsing word] )
[then]
Suddenly, compilation of "test(to)" failed in VfxForth, version
VFX Forth 64 5.43 [build 0199] 2023-11-09 for Linux x64
So, either this "test(to)" or VfxForth is not standard compliant.
: test-to 1 to _v1 ;^
If I redefine a CONSTANT SIZE , I rather use the standard
1,000,000,000 'SIZE >DFA !
instead of using a VALUE.
On Thu, 1 Aug 2024 12:01:06 +0000, albert@spenarnc.xs4all.nl wrote:
If I redefine a CONSTANT SIZE , I rather use the standard
1,000,000,000 'SIZE >DFA !
instead of using a VALUE.
Variable constants should be in everyone's toolbox. :o)
TO is not part of the CORE wordset, and the standard has no
normative parts
- only compliance requirements, which do not
include TO. See standard section 5.
Don't nail your own foot to the floor...
Do not agree?
Am I the only one that thinks parsing words are an incredible nuisance?
However, as I showed earlier, a parsing "TO" has several advantages over
a non-parsing "TO".
[..] I've sometimes thought of a version
of VALUE that makes two separate words, for reading and writing the
value:
17 XVALUE foo
creates two words, "?foo" and "!foo". ?foo pushes the value from foo (initially 17) onto the stack. !foo moves TOS to foo.
Am I the only one that thinks parsing words are an incredible nuisance?
However, as I showed earlier, a parsing "TO" has several advantages over
a non-parsing "TO".
Am I the only one that thinks parsing words are an incredible nuisance?
-marcel
However, as I showed earlier, a parsing "TO" has several advantages over
a non-parsing "TO".
Am I the only one that thinks parsing words are an incredible nuisance?
On 4/08/2024 5:17 pm, mhx wrote:
However, as I showed earlier, a parsing "TO" has several advantages over >>> a non-parsing "TO".
Am I the only one that thinks parsing words are an incredible nuisance?
Don't know but to this day Mitch Bradley (ANS, Open Firmware) still uses parsing words to interpret hex, double, float numbers.
He also uses state-smart words.
On Mon, 5 Aug 2024 12:26:26 +0000, dxf wrote:
Don't know but to this day Mitch Bradley (ANS, Open Firmware) still uses
parsing words to interpret hex, double, float numbers.
"de gustibus non disputandum est."
He also uses state-smart words.
Show me a Forther *without* strong opinions *and* unfathomable >inconsistencies.
mhx@iae.nl (mhx) writes:
On Mon, 5 Aug 2024 12:26:26 +0000, dxf wrote:
Don't know but to this day Mitch Bradley (ANS, Open Firmware) still uses >>> parsing words to interpret hex, double, float numbers.
"de gustibus non disputandum est."
He also uses state-smart words.
Show me a Forther *without* strong opinions *and* unfathomable >>inconsistencies.
In this case it's actually consistent: Mitch Bradley finds the
pitfalls of STATE-smart words acceptable, so he uses such words to
deal with various literals.
I, OTOH, don't consider them to be acceptable, so I prefer
recognizers, like the standard already has for words, single and
double integer numbers, and FP numbers.
- anton
On 6/08/2024 2:27 pm, dxf wrote:
...
ISTR dual-xt solutions also have problems with 'edge cases'.
Works for state-smart but not dual-xt:
: ," postpone s" dup c, here over allot swap cmove ;
," Hello world"
On 6/08/2024 2:27 pm, dxf wrote:
...
ISTR dual-xt solutions also have problems with 'edge cases'.
Works for state-smart but not dual-xt:
: ," postpone s" dup c, here over allot swap cmove ;
," Hello world"
Perhaps it's time to consider all 'smart' words 'evil'.
Numbers (also denotations, such as strings) must be smart.
albert@spenarnc.xs4all.nl writes:
Numbers (also denotations, such as strings) must be smart.
I've thought of having non-smart numbers in a small Forth. Instead of
123 you would say # 123 or something similar, where # is a parsing word
that emits LIT and the number. I remember that the eForth metacompiler
does something like that, to handle the case where the host and target >processors have differing number representations (e.g. word sizes).
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 475 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 19:55:58 |
| Calls: | 9,487 |
| Calls today: | 6 |
| Files: | 13,617 |
| Messages: | 6,121,093 |