In article <v8dntr$1lcff$
1@dont-email.me>,
Ruvim <
ruvim.pinka@gmail.com> wrote:
On 2024-07-31 13:41, mhx wrote:
On Wed, 31 Jul 2024 9:08:43 +0000, Gerry Jackson wrote:
[..]
111 value x x . 111 ok
222 to cr .( Does TO parse? ) x x 222 = [if] .( No it doesn't!) [then]
Does TO parse? No it doesn't! ok
[..]
As does iForth.
You could argue that it's not a standard program because it contains a
deliberate ambiguous condition so a parsing TO would fail in some way
but it does demonstrate non-compliant behaviour.
222 TO cr
should (I hope!) produce an exception (unless CR is redefined),
so this *definitely* fails and doesn't even finish the test.
I'm not sure that you can use a buggy program to test for an ambiguous
condition (looks like a top job for an eager lawyer). It would be
much better if the anomaly can be shown with a valid program.
When we want to apply a parsing word to a calculated string, we can use >"execute-parsing" (that can be defined in a standard way [1]). For a not >parsing "to", this standard-compliant method will fail.
A testcase:
: apply-compiling(to) ( sd.name -- )
[: postpone to ;] execute-parsing
;
This is foreseen. The standard stipulates that is not allowed
to POSTPONE TO
<SNIP>
If I redefine a CONSTANT SIZE , I rather use the standard
1,000,000,000 'SIZE >DFA !
instead of using a VALUE.
--
Ruvim
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)