Path: ...!2.eu.feeder.erje.net!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: Re: VALUE and TO implementation
Date: Thu, 01 Aug 2024 10:07:30 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 82
Message-ID: <2024Aug1.120730@mips.complang.tuwien.ac.at>
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>
Injection-Date: Thu, 01 Aug 2024 13:17:30 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="9c6cb8df3cbe72c15b04922cd88fdb90";
	logging-data="2256840"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/ajwb5gLKpaDGcS1r80Z8s"
Cancel-Lock: sha1:oksr9Y2wMItNi5tkFCwF0NYl5To=
X-newsreader: xrn 10.11
Bytes: 3567

Ruvim <ruvim.pinka@gmail.com> writes:
>On 2024-07-31 21:33, Anton Ertl wrote:
>> 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?

That's up to those to work out who would benefit from such a
restriction.  The alternative (which may require less work) is to
implement TO in a way that makes such a restriction unnecessary (i.e.,
such that POSTPONE TO works even with a user-defined and maybe also
the system-defined POSTPONE).

>Disallow obtaining the name token for "to"? That's a very weak 
>approach.

That appears to be overly blunt to me and would be unlikely to gain my
support.

>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]

This is clever.  Given that your test uses only Forth-94 features,
already Forth-94 can see the difference between parsing and
non-parsing TO.

>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 see nothing here that makes TEST(TO) non-standard.  One can condense
the case where VFX fails into:

0 value _v1 immediate
: test-to 1 to _v1 ;

VFX Forth 64 5.43 [build 0199] reacts with:

Err# -4 ERR: Data stack underflow.
 -> : test-to 1 to _v1 ;
                      ^

Let's see how your test works for the original flag-setting TO
(without optimizations):

variable to-state false to-state !
: to true to-state ! ;
: value
    create ,
  does>
    to-state @ if
      ! false to-state !
    else
      @
    then ;

Your test indeed outputs "["to" is not a parsing word]".

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: https://forth-standard.org/
   EuroForth 2024: https://euro.theforth.net