From: ruvim.pinka@gmail.com
On 2024-07-31 21:33, Anton Ertl wrote:
> Ruvim writes:
>> A testcase:
>>
>> : apply-compiling(to) ( sd.name -- )
>> [: postpone to ;] execute-parsing
>> ;
>
> The standard says (in 6.2.2295):
>
> |An ambiguous condition exists if any of POSTPONE, [COMPILE], ' or [']
> |are applied to TO.
Yes, that is why I added the note below.
>> NB: "postpone" can be defined in a standard way via "find-name" so that
>> is apples to "to" [2].
>
> But FIND-NAME is not in Forth-2012.
Yes. But "find-name" has already been accepted, and, anyway, it can be
implemented via "get-order" and "traverse-wordlist".
> 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.
I changed "test(to)" to make it compilable in VfxForth:
: ndrop ( i*x u.i -- ) 0 ?do drop loop ;
2 value _v1 immediate
0 value _v2
: test(to) ( -- )
depth >r 1
[ 0 1 ] to _v1 _v2 [ ( 0 | 0 1 | 0 1 2 ) ndrop ]
( | 1 | 1 0 ) depth r> - ndrop
;
\ in this point _v1 and _v2 shall be unchanged,
\ but _v1 is changed in VfxForth
_v1 2 <> [if]
.( [error, _v1 is changed during compilation] )
[then]
_v2 0 <> [if]
.( [error, _v2 is changed during compilation] )
[then]
\ Check what variable is changed by "test(to)"
0 to _v1
0 to _v2
test(to)
_v1 [if]
.( ["to" is a parsing word] )
[else]
_v2 [if]
.( ["to" is not a parsing word] )
[else] \ neither _v1 nor _v2 is changed
.( ["to" is implemented incorrectly] )
[then] [then]
In this test, VfxForth falls into third case, ["to" is implemented
incorrectly].
I redefined "to" in VfxForth as following:
: to ( "ccc" -- ) ( run-time: x -- )
' ['] to ( xt.argument xt.to )
state @ if compile, compile, else execute execute then
; immediate
And it did not change anything in the above tests!
It looks like "compile," in VfxForth still violates the standard, having
unspecified detectable side effects.
> Note that FIND and SEARCH-WORDLIST are alreading in Forth-94,
> and TRAVERSE-WORDLIST is in Forth-2012.
As well as "name>compile" (to define "postpone").
Regarding "find" — it's possible to use "find" to implement "postpone"
only if "find" is implemented in such a way that the interpreter loop
from a single-xt+immediacy-flag system correctly works.
For example, the following "interpret":
: tt-xt ( i*x xt -- j*x )
state @ if compile, else execute then
;
: tt-word ( i*x xt flag.special -- j*x )
if execute exit then tt-xt
;
: interpret ( i*x -- j*x )
begin
bl word find dup if 1 =
tt-word
else drop count dup if \ try to recognize a number
\ ...
-13 throw
else 2drop exit then then
again
;
--
Ruvim
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
