Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Ruvim <ruvim.pinka@gmail.com>
Newsgroups: comp.lang.forth
Subject: Re: VALUE and TO implementation
Date: Thu, 1 Aug 2024 04:21:30 +0400
Organization: A noiseless patient Spider
Lines: 154
Message-ID: <v8ekea$1po8g$1@dont-email.me>
References: <a1aab44ee3b1b56c2f54f2606e98d040@www.novabbs.com>
 <v8b04c$137lg$1@dont-email.me> <nnd$6e668a8e$712b1a09@1b1e479e823969fb>
 <v8cuur$1go8k$1@dont-email.me>
 <2af79ef5abcec71a1d42a461b6bc56b8@www.novabbs.com>
 <v8dntr$1lcff$1@dont-email.me> <2024Jul31.193344@mips.complang.tuwien.ac.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 01 Aug 2024 02:21:30 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d1be1ae417856d29403db8a5484ed461";
	logging-data="1892624"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18QeysFwQR82NaU59rJTLtw"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:rigQ6Lh649urlVo8HV9n3I0NmHw=
In-Reply-To: <2024Jul31.193344@mips.complang.tuwien.ac.at>
Content-Language: en-US
Bytes: 5011

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