On 2024-07-31 21:33, Anton Ertl wrote:
Ruvim <ruvim.pinka@gmail.com> 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<name>" -- ) ( 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
Operator overloading?
Re: Operator overloading?
