Path: ...!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: Sun, 4 Aug 2024 13:39:25 +0400
Organization: A noiseless patient Spider
Lines: 64
Message-ID: <v8ni8c$3vbpv$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>
 <v8ekea$1po8g$1@dont-email.me> <2024Aug1.120730@mips.complang.tuwien.ac.at>
 <v8in5k$2pq99$1@dont-email.me>
 <8d987eafbce5a4759e7d6d7d41f11723@www.novabbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 04 Aug 2024 11:39:25 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="63276c1af273ee57036b42cd771ae614";
	logging-data="4173631"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/0UWYqidPzOOd3PK3urpnm"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:yCyBFFMlM32nRTD6RPiLFbTZajg=
In-Reply-To: <8d987eafbce5a4759e7d6d7d41f11723@www.novabbs.com>
Content-Language: en-US
Bytes: 3149

On 2024-08-03 14:49, mhx wrote:
> FORTH> 0 value _v1 immediate  ok
> FORTH> : test-to 1 to _v1 ;  ok
> FORTH> see test-to
> Flags: TOKENIZE, ANSI
> : test-to  1 TO _v1 ;  ok
> FORTH> : tt test-to _v1 . ;  ok
> FORTH> see tt
> Flags: ANSI
> $01341640  : tt
> $0134164A  mov           $01341190 qword-offset, 1 d#
> $01341655  push          $01341190 qword-offset
> $0134165B  jmp           .+10 ( $0124A102 ) offset NEAR
> FORTH> tt 1  ok
> FORTH>
> 
> FWIW.

This shows how a non-parsing "TO" in iForth passes Anton's test, doesn't it?

I can guess, "TO" in iForth changes how the Forth text interpreter 
translates the next lexeme.

Conceptually, something like this:

   defer translate-lexeme
   ' translate-lexeme-default is translate-lexeme

   : interpret
     begin parse-name dup if translate-lexeme repeat 2drop
   ;

   : to
     [: ( sd.name -- | x sd.name -- )
         ['] translate-lexeme-default is translate-lexeme
         find-name ?found ( nt | x nt )
         name>action(to) ( xt | x xt )
         state @ if compile, else execute then
     ;]
     is translate-lexeme
   ; immediate


A parsing "to" can be defined via this variant as follows:

   : to ( "name" -- | x "name" -- )
     ['] to execute  parse-name evaluate
   ; immediate



My "test(to)" fails to detect this implementation variant for "to" as 
non-parsing. A special test should be used to detect namely this variant.

Obviously, this non-parsing variant of "TO" fails when used with 
"execute-parsing".

A similar bug win non-parsing "[if]" and "[else]" was fixed in Gforth in 
2018, see <https://github.com/forthy42/gforth/issues/16>


--
Ruvim