Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #134869 > unrolled thread

Coroutines in Forth

Back to article view | Back to comp.lang.forth

Contents

  Coroutines in Forth Gerry Jackson <do-not-use@swldwa.uk> - 2026-04-05 23:25 +0100
    Re: Coroutines in Forth Gerry Jackson <do-not-use@swldwa.uk> - 2026-04-05 23:30 +0100
      Re: Coroutines in Forth Paul Rubin <no.email@nospam.invalid> - 2026-04-05 17:16 -0700
        Re: Coroutines in Forth Gerry Jackson <do-not-use@swldwa.uk> - 2026-04-06 19:58 +0100
          Re: Coroutines in Forth Paul Rubin <no.email@nospam.invalid> - 2026-04-22 11:13 -0700
            Re: Coroutines in Forth albert@spenarnc.xs4all.nl - 2026-04-22 22:05 +0200
        Re: Coroutines in Forth albert@spenarnc.xs4all.nl - 2026-04-07 13:23 +0200
    Re: Coroutines in Forth albert@spenarnc.xs4all.nl - 2026-04-06 13:51 +0200
      Re: Coroutines in Forth Gerry Jackson <do-not-use@swldwa.uk> - 2026-04-06 22:20 +0100
        Re: Coroutines in Forth albert@spenarnc.xs4all.nl - 2026-04-07 13:35 +0200
          Re: Coroutines in Forth Gerry Jackson <do-not-use@swldwa.uk> - 2026-04-07 20:55 +0100
            Re: Coroutines in Forth albert@spenarnc.xs4all.nl - 2026-04-08 12:34 +0200
              Re: Coroutines in Forth Gerry Jackson <do-not-use@swldwa.uk> - 2026-04-08 12:32 +0100
              non-parsing `TO` considered harmful Ruvim <ruvim.pinka@gmail.com> - 2026-06-04 22:26 +0000
                Re: non-parsing `TO` considered harmful Ruvim <ruvim.pinka@gmail.com> - 2026-06-06 12:54 +0000
                  Re: non-parsing `TO` considered harmful anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-06-06 16:17 +0000
                    Re: non-parsing `TO` considered harmful Ruvim <ruvim.pinka@gmail.com> - 2026-06-06 21:09 +0000
                      Re: non-parsing `TO` considered harmful anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-06-07 13:23 +0000
                        Re: non-parsing `TO` considered harmful Ruvim <ruvim.pinka@gmail.com> - 2026-06-07 17:44 +0000
                          Re: non-parsing `TO` considered harmful anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-06-08 05:04 +0000
                            text translator (was: non-parsing `TO` considered harmful) Ruvim <ruvim.pinka@gmail.com> - 2026-06-08 15:53 +0000
                            Recognizers vs Parsing words (was: non-parsing `TO` considered harmful) Ruvim <ruvim.pinka@gmail.com> - 2026-06-09 10:25 +0000
                              Re: Recognizers vs Parsing words Ruvim <ruvim.pinka@gmail.com> - 2026-06-10 19:45 +0000
                        compilation of compilation (was: non-parsing `TO` considered harmful) Ruvim <ruvim.pinka@gmail.com> - 2026-06-08 07:28 +0000
                        Recognizer API v.2025-09-11 (was: non-parsing `TO` considered harmful) Ruvim <ruvim.pinka@gmail.com> - 2026-06-14 12:41 +0000
                          Re: Recognizer API v.2025-09-11 (was: non-parsing `TO` considered harmful) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-06-15 17:17 +0000
                            Re: Recognizer API v.2025-09-11 Ruvim <ruvim.pinka@gmail.com> - 2026-06-16 17:34 +0000
                              Re: Recognizer API v.2025-09-11 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-06-17 05:05 +0000
                                Setters and getters in APIs (was: Recognizer API v.2025-09-11) Ruvim <ruvim.pinka@gmail.com> - 2026-06-19 16:17 +0000
                                  Re: Setters and getters in APIs (was: Recognizer API v.2025-09-11) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-06-20 15:51 +0000
                    Re: non-parsing `TO` considered harmful Stephen Pelc <stephen@vfxforth.com> - 2026-06-07 11:59 +0000
                      Re: non-parsing `TO` considered harmful anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-06-07 15:25 +0000
            Re: Coroutines in Forth Stephen Pelc <stephen@vfxforth.com> - 2026-04-09 10:12 +0000
              non-parsing `TO` considered harmful Ruvim <ruvim.pinka@gmail.com> - 2026-06-04 22:30 +0000
                VFX Forth problems Ruvim <ruvim.pinka@gmail.com> - 2026-06-05 16:24 +0000
              Re: Coroutines in Forth marcel hendrix <mhx@iae.nl> - 2026-07-09 09:50 +0200
                Re: Coroutines in Forth albert@SPENARNC.XS4ALL.NL - 2026-07-10 01:48 +0200
            Re: Coroutines in Forth Stephen Pelc <stephen@vfxforth.com> - 2026-06-07 11:53 +0000
              non-parsing `TO` considered harmful (was: Coroutines in Forth) Ruvim <ruvim.pinka@gmail.com> - 2026-06-07 13:31 +0000
                Re: non-parsing `TO` considered harmful Travis Bemann <tabemann@gmail.com> - 2026-08-28 20:36 -0500
          Re: Coroutines in Forth Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-10 19:01 +0200
            Re: Coroutines in Forth dxf <dxforth@gmail.com> - 2026-04-11 11:54 +1000
              Re: Coroutines in Forth Hans Bezemer <the.beez.speaks@gmail.com> - 2026-05-01 13:07 +0200
            Re: Coroutines in Forth peter <peter.noreply@tin.it> - 2026-04-11 09:49 +0200
            Re: Coroutines in Forth albert@spenarnc.xs4all.nl - 2026-04-11 22:03 +0200
              Re: Coroutines in Forth dxf <dxforth@gmail.com> - 2026-04-12 12:49 +1000
                Re: Coroutines in Forth albert@spenarnc.xs4all.nl - 2026-04-12 12:13 +0200
                  Re: Coroutines in Forth Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-12 17:39 +0200
                    Re: Coroutines in Forth dxf <dxforth@gmail.com> - 2026-04-13 10:54 +1000
                      Re: Coroutines in Forth Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-13 19:24 +0200
                Re: Coroutines in Forth Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-12 13:48 +0200
                Re: Coroutines in Forth albert@spenarnc.xs4all.nl - 2026-04-13 12:13 +0200
                Re: Coroutines in Forth Paul Rubin <no.email@nospam.invalid> - 2026-04-22 11:18 -0700
                  Re: Coroutines in Forth dxf <dxforth@gmail.com> - 2026-04-23 11:13 +1000
                  Re: Coroutines in Forth Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-23 12:37 +0200
                    Re: Coroutines in Forth Paul Rubin <no.email@nospam.invalid> - 2026-04-24 10:36 -0700
                      Re: Coroutines in Forth dxf <dxforth@gmail.com> - 2026-04-25 12:12 +1000
                        Re: Coroutines in Forth Paul Rubin <no.email@nospam.invalid> - 2026-04-24 23:31 -0700
                          Re: Coroutines in Forth albert@spenarnc.xs4all.nl - 2026-04-25 10:45 +0200
                          Re: Coroutines in Forth dxf <dxforth@gmail.com> - 2026-04-25 22:06 +1000
                            Re: Coroutines in Forth Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-25 15:11 +0200
                              Re: Coroutines in Forth dxf <dxforth@gmail.com> - 2026-04-26 13:33 +1000
                                Re: Coroutines in Forth Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-26 16:28 +0200
                              Re: Coroutines in Forth Paul Rubin <no.email@nospam.invalid> - 2026-04-25 21:46 -0700
                                FP stack depth limitations (was: Coroutines in Forth) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-26 05:55 +0000
                                  Re: FP stack depth limitations Paul Rubin <no.email@nospam.invalid> - 2026-04-26 00:28 -0700
                                    Re: FP stack depth limitations dxf <dxforth@gmail.com> - 2026-04-26 19:55 +1000
                                  Re: FP stack depth limitations (was: Coroutines in Forth) peter <peter.noreply@tin.it> - 2026-04-26 09:57 +0200
                                    Re: FP stack depth limitations (was: Coroutines in Forth) albert@spenarnc.xs4all.nl - 2026-04-26 14:34 +0200
                          Re: Coroutines in Forth Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-25 15:01 +0200
                      Re: Coroutines in Forth Hans Bezemer <the.beez.speaks@gmail.com> - 2026-05-01 13:13 +0200
                    Forth, C, hardware, and programming virtues (was: Coroutines in Forth) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-25 05:26 +0000
                      Re: Forth, C, hardware, and programming virtues Paul Rubin <no.email@nospam.invalid> - 2026-04-24 23:55 -0700
                        Re: Forth, C, hardware, and programming virtues anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-25 08:21 +0000
                        Re: Forth, C, hardware, and programming virtues albert@spenarnc.xs4all.nl - 2026-04-25 11:27 +0200
                      Re: Forth, C, hardware, and programming virtues Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-25 15:43 +0200
                        Re: Forth, C, hardware, and programming virtues anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-25 17:21 +0000
                          Re: Forth, C, hardware, and programming virtues dxf <dxforth@gmail.com> - 2026-04-26 15:21 +1000
                          Re: Forth, C, hardware, and programming virtues Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-26 15:08 +0200
                        Re: Forth, C, hardware, and programming virtues albert@spenarnc.xs4all.nl - 2026-04-26 00:34 +0200
                          Re: Forth, C, hardware, and programming virtues Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-26 15:10 +0200
                  locals (was: Coroutines in Forth) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-25 04:47 +0000
                    Re: locals Paul Rubin <no.email@nospam.invalid> - 2026-04-24 23:21 -0700
                      Re: locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-25 06:43 +0000
                        Re: locals albert@spenarnc.xs4all.nl - 2026-04-25 11:43 +0200
                          Re: locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-25 10:22 +0000
                            Re: locals peter <peter.noreply@tin.it> - 2026-04-25 16:07 +0200
                              Re: locals Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-25 17:38 +0200
                                Re: locals albert@spenarnc.xs4all.nl - 2026-04-26 01:13 +0200
                              Re: locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-26 14:03 +0000
                                Re: locals peter <peter.noreply@tin.it> - 2026-04-27 09:31 +0200
                                  Re: locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-27 07:53 +0000
                                    Re: locals peter <peter.noreply@tin.it> - 2026-04-27 11:52 +0200
                            Re: locals albert@spenarnc.xs4all.nl - 2026-04-26 00:51 +0200
                        Re: locals Paul Rubin <no.email@nospam.invalid> - 2026-04-25 22:40 -0700
                          Re: locals albert@spenarnc.xs4all.nl - 2026-04-26 14:55 +0200
                          Re: locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-26 09:50 +0000
                            Re: locals Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-26 16:22 +0200
                              Re: locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-26 17:04 +0000
                                Re: locals dxf <dxforth@gmail.com> - 2026-04-27 11:51 +1000
                                Re: locals Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-28 08:21 +0200
                                Re: locals Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-28 08:22 +0200
                            Re: locals dxf <dxforth@gmail.com> - 2026-04-27 11:12 +1000
                              Re: locals Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-28 14:34 +0200
                              Re: locals Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-28 14:34 +0200
                                Re: locals Gerry Jackson <do-not-use@swldwa.uk> - 2026-04-29 12:44 +0100
                                  Re: locals Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-29 14:37 +0200
                                    Re: locals Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-29 14:44 +0200
                            Re: locals Paul Rubin <no.email@nospam.invalid> - 2026-05-01 23:50 -0700
                              Re: locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-05-02 10:34 +0000
                            Re: locals Paul Rubin <no.email@nospam.invalid> - 2026-05-01 23:54 -0700
                              Re: locals dxf <dxforth@gmail.com> - 2026-05-02 17:36 +1000
                                Re: locals Paul Rubin <no.email@nospam.invalid> - 2026-05-02 01:11 -0700
                              Re: locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-05-02 15:58 +0000
        Re: Coroutines in Forth Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-04-07 09:28 -0500
          Re: Coroutines in Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-07 16:12 +0000
            Re: Coroutines in Forth Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-04-07 18:06 -0500
            Re: Coroutines in Forth Gerry Jackson <do-not-use@swldwa.uk> - 2026-04-08 11:43 +0100
              Re: Coroutines in Forth albert@spenarnc.xs4all.nl - 2026-04-08 13:16 +0200
                Re: Coroutines in Forth Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-04-08 11:47 -0500
                  Re: Coroutines in Forth Gerry Jackson <do-not-use@swldwa.uk> - 2026-04-08 21:48 +0100
                    Re: Coroutines in Forth Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-04-09 07:06 -0500
                      Re: Coroutines in Forth albert@spenarnc.xs4all.nl - 2026-04-09 16:41 +0200
                        Re: Coroutines in Forth Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-04-09 13:34 -0500
                          Re: Coroutines in Forth albert@spenarnc.xs4all.nl - 2026-04-10 01:23 +0200
                            Re: Coroutines in Forth Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-04-09 21:34 -0500
                  Re: Coroutines in Forth albert@spenarnc.xs4all.nl - 2026-04-09 13:01 +0200
                    Re: Coroutines in Forth Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-04-09 07:01 -0500
                      Re: Coroutines in Forth albert@spenarnc.xs4all.nl - 2026-04-09 16:10 +0200
                        Re: Coroutines in Forth Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-04-09 13:29 -0500
                Re: Coroutines in Forth Gerry Jackson <do-not-use@swldwa.uk> - 2026-04-08 21:26 +0100
            Re: Coroutines in Forth Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-08 14:22 +0200
            Re: Coroutines in Forth Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-28 15:31 +0200
              Re: Coroutines in Forth albert@spenarnc.xs4all.nl - 2026-04-29 10:49 +0200
                Re: Coroutines in Forth Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-29 15:22 +0200
          Re: Coroutines in Forth Gerry Jackson <do-not-use@swldwa.uk> - 2026-04-08 11:33 +0100
            Re: Coroutines in Forth albert@spenarnc.xs4all.nl - 2026-04-08 13:07 +0200
              Re: Coroutines in Forth Gerry Jackson <do-not-use@swldwa.uk> - 2026-04-08 22:05 +0100
    Re: Coroutines in Forth albert <albert@spenarnc.xs4all.nl> - 2026-06-21 01:26 +0200

Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7  Next page →

#135152 — text translator (was: non-parsing `TO` considered harmful)

On 2026-06-08 05:04, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
>> On 2026-06-07 13:23, Anton Ertl wrote:
[...]
>>> Any word that is not the text interpreter and that uses "STATE @" is
>>> deficient.
>>>
>>
>> I would classify my word `to(` is a text interpreter. Is it still deficient?
> 
> Yes, because it is no text interpreter, and playing Humpty-Dumpty does
> not change that.  E.g.,
> 
> to( : foo 1 + . ; 2 foo )
> 
> does not print 3.

Ah, you meant the Forth text interpreter. I see.

I understood/meant the term "text interpreter" in a more general sense. 
I usually prefer to use the term "translator" for that (see bellow), 
since interpretation often implies execution.


>> [...]
>>>>>
>>>>> So here's the implementation (untested):
>>>>>
>>>>> : to(
>>>>>      0 0 2>r begin
>>>>>         parse-name dup 0= abort" unfinished TO("
>>>>>         2dup 2>r
>>>>>         s" )" str= until
>>>>>      2r> 2drop \ get rid of ")"
>>>>>      begin
>>>>>         2r> dup while
>>>>>             [: "to " type ;] >string-execute evaluate
>>>>>             \ freeing the strings is left as exercise to the reader
>>>>>      repeat
>>>>>      2drop \ get rid of 0 0
>>>>> ; immediate
>>>>
[...]

>>> 2) No STATE @ deficiency.
>>
>> Your definition also contains `STATE @`, but indirectly, inside
>> `evaluate`.
> 
> Yes, good point, as mentioned: Accidental capture of identifiers is
> not to only problem of EVALUATE-based macros, even in this case.  

> The problem is that the text interpreter inside the EVALUATE
> invocations use the STATE at the run-time of TO(, not at the parsing
> time.

That is, the execution semantics of `to(` uses `STATE` and that is a 
problem. In the same time, the execution semantics of `evaluate` also 
uses `STATE`, and that is not a problem. Correct?

Why do you think it is a problem in the first place, but not in the 
second place?


There are words that translate a fragment of the input source (a lexical 
block) into some other form according to their own rules. I call them 
text translators (or, translators of the input source).

For example, the standard word `code` can be implemented as a text 
translator. <https://forth-standard.org/standard/tools/CODE>

Moreover, in this sense, all immediate parsing words are text translators.

Translation (as a process) can depend on STATE, as well as on other 
pieces of the lexical context.

It is totally unclear why do you think that a text translator should not 
use STATE.


--
Ruvim

[toc] | [prev] | [next] | [standalone]

#135159 — Recognizers vs Parsing words (was: non-parsing `TO` considered harmful)

On 2026-06-08 05:04, Anton Ertl wrote:
[...]
> One way to handle that would be to disallow using ', ['], POSTPONE and
> [COMPILE] on TO(, but
> 
> 1) The Forth standard does not give us a way to enforce that.
> 
> 2) As your TO( implementation shows, such a restriction can become a
> hindrance.
> 
> Another way to handle that is to have a recognizer that deals with
> TO(.
> That solves objection 1) above, but not necessarily objection 2).


In 2019, I considered an approach that uses recognizers for lexemes 
"to", "action-of", "is", etc, instead of providing the corresponding 
Forth words, simply to technically disallow ticking them (i.e., 
obtaining their execution tokens). I then abandoned this approach. The 
reasons are as follows.

1. This approach contradicts the spirit of the section "3.4.3.2 
Interpretation semantics", which says:

   | A system shall be capable of executing,
   | in interpretation state, all of the definitions
   | from the Core word set and any definitions included
   | from the optional word sets or word set extensions
   | whose interpretation semantics are defined
   | by this standard.

And other sections, e.g. "3.4.2 Finding definition names", which says:
   | A system shall be capable of finding the definition names
   | defined by this standard


2. Providing a recognizer for a lexeme instead of providing a word (of 
the same name as the lexeme) does not prevent us from obtaining an 
execution token, since we can still obtain it like this:

   [undefined] perceive [if]
     : perceive ( sd -- any td | 0 ) rec-forth ;
   [then]

   [:
       [ s" to" perceive ?found 2lit, ] execute
   ;] ( xt )
   constant xt-of(to)

   \ NB: in this approach, "to" is not a Forth word.
   \ Then, the following definition for `[to]` should work
   \ as the standard `to` word.
   : [to]  xt-of(to) execute ; immediate


This works in the Gforth and SP-Forth/4 recognizers implementations.



> However, maybe the user who wants to do something which would
> require POSTPONEing or ticking a word TO( can do manage to do what
> they want with the recognizer, the translator, or the translator's
> actions.


Currently, in other Forth system, obtaining an execution token may 
differ from the example above, but there are no conceptual limitations.


So, conceptually, recognizers *allow* us to obtain/create an execution 
token for any *unordinary word*, which identifies the behavior that 
implements the interpretation semantics in interpretation state and the 
compilation semantics in compilation state for the word.




In general, recognizers are suitable in the following cases:
   - the behavior cannot be implemented with a single word (as for a 
string literal starter, numeric literals, etc);
   - the recognizing of a lexeme (or the beginning of a construct) 
should not depend on the search order (or be shadowed by words from the 
search order);
   - reuse of the Forth text interpreter for translating text by 
different rules (especially, through nested input sources; for example, 
`execute-parsing` can be implemented using the Recognizer API);


Otherwise, using a parsing word is also perfectly suitable.


Whether it is a parsing word or another construct, it is better if the 
affected lexical block (its beginning and end) is visually marked.

Therefore, `to( foo )` is better than `to foo`.



--
Ruvim

[toc] | [prev] | [next] | [standalone]

#135163 — Re: Recognizers vs Parsing words

On 2026-06-09 10:25, Ruvim wrote:
> 
> In general, recognizers are suitable in the following cases:
>    - the behavior cannot be implemented with a single word (as for a 
> string literal starter, numeric literals, etc);
>    - the recognizing of a lexeme (or the beginning of a construct) 
> should not depend on the search order (or be shadowed by words from the 
> search order);
>    - reuse of the Forth text interpreter for translating text by 
> different rules (especially, through nested input sources; for example, 
> `execute-parsing` can be implemented using the Recognizer API);
> 
> 
> Otherwise, using a parsing word is also perfectly suitable.
> 
> 
> Whether it is a parsing word or another construct, it is better if the 
> affected lexical block (its beginning and end) is visually marked.
> 
> Therefore, `to( foo )` is better than `to foo`.
> 


The case of `to( ... )`, if implemented using a nested call to the Forth 
text interpreter, falls into the third category — reusing the Forth text 
interpreter. However, we don't have a Forth text interpreter factor that 
would apply only to the next lexical block in the input source. And even 
if we did, it would not simplify the implementation, since in this case 
the contained lexemes must be translated in *reverse order*.


Furthermore, we currently cannot use recognizers (namely, the perceptor, 
the recognizer used by the Forth text interpreter) because we have 
neither `to` factors applicable to typed data objects (results of 
recognizers), nor `to` factors applicable to xt of 
`value`/`2value`/`fvalue` children and to local-id of local 
variables/values.

But if we do have the latter `to` factors, then using them and the 
perceptor, the word `to(` can be implemented as follows (with a bit of 
compatibility layer at the beginning):

   : equals ( sd1 sd2 -- flag ) compare 0= ;

   synonym take-lexeme-maybe parse-name

   : extract-lexeme ( -- sd )
     begin take-lexeme-maybe dup if exit then
       2drop  refill 0=
     until -39 throw \ "unexpected end of the input source"
   ;

   ' translate-xtval-setter constant td-xtval-setter
   ' translate-localid-setter constant td-localid-setter

   : to(
     extract-lexeme 2dup ")" equals if 2drop exit then
     perceive ?found ( tdo ) \ "tdo" stands for "typed data object"
     tdo>xtval? if ( xtval )
       td-xtval-setter 2>r
     else ( tdo ) tdo>localid? if ( localid )
       ?comp td-localid-setter 2>r
     else -32 throw then then
     recurse 2r> execute
   ; immediate


Using the perceptor and the `to` factors allows us to make the `to( ... 
)` construct multi-line more easily than using the top-level word `to`, 
since we don't have to allocate and free strings.

This approach works in SP-Forth/4.

The word `td-xtval-setter ( -- td )` returns the same type descriptor as 
a proper recognizer returns for "->foo", where "foo" is a children of 
`value`.

The word `td-localid-setter ( -- td )` returns the same type descriptor 
as a proper recognizer returns for "->bar", where "bar" is a local variable.

The word `tdo>xtval? ( tdo1 -- xtval true | tdo1 false )` converts tdo 
to xtval (a subtype of xt).

The word `tdo>localid? ( tdo1 -- localid true | tdo1 false )` converts 
tdo to localid.



Note: Above I use the data type symbol "tdo" rather than the proposed by 
Anton data type symbol "translation", as the latter is too confusing in 
this context, because the English "translation" means either an act of 
translating, or a result of translating [1]
[1] <https://en.wiktionary.org/wiki/translation#Noun>



--
Ruvim

[toc] | [prev] | [next] | [standalone]

#135147 — compilation of compilation (was: non-parsing `TO` considered harmful)

On 2026-06-07 13:23, Anton Ertl wrote:
[...]

> There is one thing that this TO( cannot do: It does not work as
> intended inside ]] ... [[.  And if somebody writes
> 
> POSTPONE TO( a b )
> 
> they will not get the equivalent of
> 
> POSTPONE ->b POSTPONE ->a

This behavior is unexpected, because `POSTPONE TO( a b )` is 
grammatically incorrect in Forth. Since, in this case, while compiling 
the containing definition, `postpone` appends the compilation semantics 
of `to(` to the current definition. And the fragment "a b )" remains in 
the parse area.

This is a known problem of the `]] .. [[` construct, stemming from the 
fact that it relies on `postpone`. Inside this construct, parsing words 
do not parse.

My `c{ ... }c` construct [3] does not have this drawback, but it is more 
complex to implement. Nevertheless, it should work on standard Forth 
systems.

[3] <https://github.com/ruv/forth-on-forth/blob/master/c-state.readme.txt>


> Can we deal with this by defining a recognizer for TO(, which could
> then use the TRANSLATE-TO designed for REC-TO?

This should be solved on the level of `compile,` and `lit,`, (where 
parsing is already complete), not on the level of `postpone`.


> 
> 'translate-to' ( n xt - translation  ) gforth-experimental
>     xt belongs to a value-flavoured (or defer-flavoured) word, n is the
> index into the 'to-table:' for xt (see Words with user-defined TO etc.).
> Interpreting run-time: '( ... -- ... )'
> Perform the to-action with index n in the 'to-table:' of xt.  Additional
> stack effects depend on n and xt.
> 

> It is probably possible to do that, but it would be complex: The
> recognizer would produce a translation that contains all the xts of
> the value-like words, and a TRANSLATE-TO(.

But a recognizer must not parse the parse area. Additional parsing, if 
it is needed, is performed by the translator that the recognizer returns.


> The TRANSLATE-TO( action
> for interpreting would have to get all of the xts out of the way.  The
> it woul get the xt for the last one and perform TRANSLATE-TO
> INTERPRETING; repeat for the next one, and repeat until all the xts
> are done.  The action for compiling and postponing could be
> implemented in a similar way (but call COMPILING and POSTPONING
> instead of INTERPRETING), or maybe simpler because there is no need to
> get the xts out of the way.
> 
> In any case, that's quite a bit of work.  Maybe someone (Stephen
> Pelc?) thinks this demonstrates that the recognizer words are too
> limited.  I think it demonstrates that TO( is not a good idea.


I think, it demonstrates that you shouldn't drive nails with a microscope.


--
Ruvim

[toc] | [prev] | [next] | [standalone]

#135183 — Recognizer API v.2025-09-11 (was: non-parsing `TO` considered harmful)

On 2026-06-07 13:23, Anton Ertl wrote:
[...]
> <https://forth-standard.org/proposals/recognizer-committee-proposal-2025-09-11?hideDiff#reply-1623>.
> REC-FORTH is proposed as a deferred word, but there is no requirement
> to use IS on it.  And unlike for value-flavoured words, there are
> non-parsing words for dealing with deferred words: DEFER@ and DEFER!.

As I recall, you had objections regarding the `BASE` variable 
(specifically, the use `@` and `!` as methods to get/set its value). I 
agree with them as well.

These objections also apply to the use of `DEFER@` and `DEFER!` (or 
`ACTION-OF` and `IS`) to get/set the value of a `DEFER` child.

For example, you wrote on 2024-10-05 in 
<2024Oct5.175249@mips.complang.tuwien.ac.at>:

| Forth-94 seems to have had some of that, though,
| with words like GET-CURRENT and SET-CURRENT instead
| of a (user) variable CURRENT that had existing
| practice at the time.
| I wish they had defined GET-BASE and SET-BASE
| instead of BASE.


I would like to understand why you do not apply the same reasoning to 
the Recognizers API variant you proposed.



> So if you want to define IS( ... ), there is no need to concern
> yourself with non-standard words like (TO).

In the case of the Recognizer API, the issue related to the words 
`IS`/`ACTION-OF`/`DEFER@`/`DEFER!` concerns the party providing the API 
(including a program that acts as a "wrapper" for the system while 
providing standard system functionality), rather than a program that 
merely uses the API.



--
Ruvim

[toc] | [prev] | [next] | [standalone]

#135186 — Re: Recognizer API v.2025-09-11 (was: non-parsing `TO` considered harmful)

Ruvim <ruvim.pinka@gmail.com> writes:
>On 2026-06-07 13:23, Anton Ertl wrote:
>[...]
>> <https://forth-standard.org/proposals/recognizer-committee-proposal-2025-09-11?hideDiff#reply-1623>.
>> REC-FORTH is proposed as a deferred word, but there is no requirement
>> to use IS on it.  And unlike for value-flavoured words, there are
>> non-parsing words for dealing with deferred words: DEFER@ and DEFER!.
>
>As I recall, you had objections regarding the `BASE` variable 
>(specifically, the use `@` and `!` as methods to get/set its value). I 
>agree with them as well.
>
>These objections also apply to the use of `DEFER@` and `DEFER!` (or 
>`ACTION-OF` and `IS`) to get/set the value of a `DEFER` child.
>
>For example, you wrote on 2024-10-05 in 
><2024Oct5.175249@mips.complang.tuwien.ac.at>:
>
>| Forth-94 seems to have had some of that, though,
>| with words like GET-CURRENT and SET-CURRENT instead
>| of a (user) variable CURRENT that had existing
>| practice at the time.
>| I wish they had defined GET-BASE and SET-BASE
>| instead of BASE.
>
>
>I would like to understand why you do not apply the same reasoning to 
>the Recognizers API variant you proposed.

The reason why I would have preferred SET-BASE GET-BASE over the
(user) variable BASE is that it would have allowed to do the first
stage of two-stage division in SET-BASE, and then perform the second
stage in #.

If BASE had been a UVALUE, that would have been ok, too, because I
could have used SET-TO on BASE to perform the same optimization.

Eventually I found a different way to achieve much of the same
benefit, see <2025Nov23.103631@mips.complang.tuwien.ac.at>.

- 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 2025 proceedings: http://www.euroforth.org/ef25/papers/

[toc] | [prev] | [next] | [standalone]

#135188 — Re: Recognizer API v.2025-09-11

On 2026-06-15 17:17, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
>> On 2026-06-07 13:23, Anton Ertl wrote:
>> [...]
>>> <https://forth-standard.org/proposals/recognizer-committee-proposal-2025-09-11?hideDiff#reply-1623>.
>>> REC-FORTH is proposed as a deferred word, but there is no requirement
>>> to use IS on it.  And unlike for value-flavoured words, there are
>>> non-parsing words for dealing with deferred words: DEFER@ and DEFER!.
>>
>> As I recall, you had objections regarding the `BASE` variable
>> (specifically, the use `@` and `!` as methods to get/set its value). I
>> agree with them as well.
>>
>> These objections also apply to the use of `DEFER@` and `DEFER!` (or
>> `ACTION-OF` and `IS`) to get/set the value of a `DEFER` child.
>>
>> For example, you wrote on 2024-10-05 in
>> <2024Oct5.175249@mips.complang.tuwien.ac.at>:
>>
>> | Forth-94 seems to have had some of that, though,
>> | with words like GET-CURRENT and SET-CURRENT instead
>> | of a (user) variable CURRENT that had existing
>> | practice at the time.
>> | I wish they had defined GET-BASE and SET-BASE
>> | instead of BASE.
>>
>>
>> I would like to understand why you do not apply the same reasoning to
>> the Recognizers API variant you proposed.
> 
> The reason why I would have preferred SET-BASE GET-BASE over the
> (user) variable BASE is that it would have allowed to do the first
> stage of two-stage division in SET-BASE, and then perform the second
> stage in #.
> 
> If BASE had been a UVALUE, that would have been ok, too, because I
> could have used SET-TO on BASE to perform the same optimization.

So, by all appearances, you see the advantages of using setters/getters.

`set-to` in Gforth allows to configure a setter to a child of `value` or 
`defer` that will be used by `to`. The problem with `set-to` approach is 
that it cannot be used in a standard program.

In contrast, getters and setters implemented as separate *ordinary* 
words can be defined or redefined within a standard program. And they 
are far simpler.


> 
> Eventually I found a different way to achieve much of the same
> benefit, see <2025Nov23.103631@mips.complang.tuwien.ac.at>.

Thank you for the reference.


Other legacy variables are `>in` and `state`.

In each case, there may be specific reasons why a getter or setter is 
needed.

However, the general objection against variables in an API is that they 
do not allow a system (or a wrapper) to have additional actions that are 
performed when getting or setting the value.

This objection also applies to the words created using `value` and 
`defer` (perhaps to a lesser extent in complex systems like Gforth, but 
fully so regarding simpler systems and programs/wrappers).


--
Ruvim

[toc] | [prev] | [next] | [standalone]

#135189 — Re: Recognizer API v.2025-09-11

Ruvim <ruvim.pinka@gmail.com> writes:
>On 2026-06-15 17:17, Anton Ertl wrote:
>> The reason why I would have preferred SET-BASE GET-BASE over the
>> (user) variable BASE is that it would have allowed to do the first
>> stage of two-stage division in SET-BASE, and then perform the second
>> stage in #.
>> 
>> If BASE had been a UVALUE, that would have been ok, too, because I
>> could have used SET-TO on BASE to perform the same optimization.
>
>So, by all appearances, you see the advantages of using setters/getters.
>
>`set-to` in Gforth allows to configure a setter to a child of `value` or 
>`defer` that will be used by `to`. The problem with `set-to` approach is 
>that it cannot be used in a standard program.

A standard program cannot change how # is implemented, either, so
having a standard SET-BASE would not help for the purpose I outlined
above.  If BASE was a VALUE or UVALUE, system implementors could
implement TO BASE to perform that optimization if they want; no
standard SET-BASE or SET-TO is necessary for that.

Another take on your statements is to think about standardizing
SET-TO.  For now, though, I don't think that there is enough common
practice.

>In contrast, getters and setters implemented as separate *ordinary* 
>words can be defined or redefined within a standard program. And they 
>are far simpler.
>
>
>> 
>> Eventually I found a different way to achieve much of the same
>> benefit, see <2025Nov23.103631@mips.complang.tuwien.ac.at>.
>
>Thank you for the reference.
>
>
>Other legacy variables are `>in` and `state`.
>
>In each case, there may be specific reasons why a getter or setter is 
>needed.

For STATE the standard defines the setters "[" and "]", and you are
not allowed to change STATE directly.  In Gforth we used to change a
deferred word for a part of the inner interpreter when "[" or "]" are
invoked, but eventually changed that to just read the contents of
STATE.  The deferred word did not provide a significant speedup or
simplification.

As for "there may be", Chuck Moore said "Don't speculate".  Of course
Moore does not care about APIs and would eliminate the user variable
BASE and do something else as soon as he sees a more advantageous way,
and he has done so for STATE (which is probably the reason why we have
the restriction on STATE despite not allowing the polyForth approach
to compilation mode), so his opinion may not be that relevant when
designing an API.  But still, of the three examples you mentioned:

BASE: I thought about one reason where being able to catch a change to
BASE would have been advantageous, but found a way to work without
that capability, probably with little cost.

STATE: We already have setters for that, and we have not found that to
be a significant advantage.

>IN: The word that probably uses >IN most often is PARSE-NAME, so
let's take a look:

In Gforth PARSE-NAME is a deferred word, and by default it contains:

: (name) ( -- c-addr count )
    source 2dup >r >r >in @ 2dup u< IF  -18 throw  THEN
    /string (parse-white)
    2dup input-lexeme!
    2dup + r> - 1+ r> min >in ! ;

I see a number of optimizations that could be done if we could hang
actions on to the writing and reading of >IN, e.g., have a 2variable
rest-source, and implement (name) like this:

: (name) ( -- c-addr count )
  rest-source 2@ (parse-white) 2dup input-lexeme!
  dup if 1/string then rest-source 2! ;

with corresponding extra work when setting and getting >IN, and in
SOURCE and maybe elsewhere.

Would this buy much?  One would have to measure it, but at least for
the things I have done, the parsing speed never has been a problem.

>However, the general objection against variables in an API is that they 
>do not allow a system (or a wrapper) to have additional actions that are 
>performed when getting or setting the value.
>
>This objection also applies to the words created using `value` and 
>`defer` (perhaps to a lesser extent in complex systems like Gforth, but 
>fully so regarding simpler systems and programs/wrappers).

The use of getters and setters is the mark of complex systems such as
those programmed in C++ and Java, so I doubt that simple Forth systems
would move complexity into SET->IN, GET->IN, SOURCE etc. in order to
make PARSE-NAME faster.

For the more sophisticated systems, value-flavoured and
defer-flavoured words can be implemented to allow hanging additional
actions onto the setting and getting.  And I think that this is the
way to go, given the preference towards value-flavoured words shown in
recent years by, e.g., Joerg Voelker and Nick Nelson.

- 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 2026 CFP: http://www.euroforth.org/ef26/cfp.html

[toc] | [prev] | [next] | [standalone]

#135190 — Setters and getters in APIs (was: Recognizer API v.2025-09-11)

This discussion examines the reasons why APIs (and the Recognizer API in 
particular) should provide specialized setter and getter methods instead 
of generic ones, such as `!`, `@`, `defer!`, `defer@`, `is`, 
`action-of`, or `to`.


In general, setters allow us to enforce rules before updating the value; 
also, they allows us to change the internal implementation, without 
breaking code that depends on the API. Getters allow us calculate a 
value only when it is needed, rather than storing it explicitly.

See some examples bellow.


On 2026-06-17 05:05, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
>> On 2026-06-15 17:17, Anton Ertl wrote:
>>> The reason why I would have preferred SET-BASE GET-BASE over the
>>> (user) variable BASE is that it would have allowed to do the first
>>> stage of two-stage division in SET-BASE, and then perform the second
>>> stage in #.
>>>
>>> If BASE had been a UVALUE, that would have been ok, too, because I
>>> could have used SET-TO on BASE to perform the same optimization.
>>
>> So, by all appearances, you see the advantages of using setters/getters.
>>
>> `set-to` in Gforth allows to configure a setter to a child of `value` or
>> `defer` that will be used by `to`. The problem with `set-to` approach is
>> that it cannot be used in a standard program.
> 
> A standard program cannot change how # is implemented, either, so
> having a standard SET-BASE would not help for the purpose I outlined
> above.

However, a standard program could redefine `set-base` and the words for 
pictured numeric output, such as `#`, `#s` (as well as others required 
for the program's purposes).


> If BASE was a VALUE or UVALUE, system implementors could
> implement TO BASE to perform that optimization if they want; no
> standard SET-BASE or SET-TO is necessary for that.

There is also a similar, yet more compelling counter-argument:
If a standard `SET-BASE` setter existed, then *both* system implementors 
and program authors could easily implement/use this method for 
optimization or other purposes; no standard `TO BASE` is necessary for that.



> Another take on your statements is to think about standardizing
> SET-TO.  For now, though, I don't think that there is enough common
> practice.

I don't feel the lack of such a method.

And I don't see any advantages of `TO BASE` over `SET-BASE` in terms of 
*usage*.

The advantage of `SET-BASE` is that it can be easily redefined, allowing 
the program/wrapper to add additional actions in a standard way.



>> In contrast, getters and setters implemented as separate *ordinary*
>> words can be defined or redefined within a standard program. And they
>> are far simpler.
>>
>>
>>>
>>> Eventually I found a different way to achieve much of the same
>>> benefit, see <2025Nov23.103631@mips.complang.tuwien.ac.at>.
>>
>> Thank you for the reference.
>>
>>
>> Other legacy variables are `>in` and `state`.
>>
>> In each case, there may be specific reasons why a getter or setter is
>> needed.
> 
> For STATE the standard defines the setters "[" and "]", and you are
> not allowed to change STATE directly.

Yes, in this case we have a kind of setters, but not a getter. 
Therefore, `state @ 0<>` is merely an archaism we are forced to use due 
to the lack of a proper getter.

The words `[` and `]` are high-level words, they are inconvenient for 
programmatically changing the state.

I use the following words in my programs:

   : compilation ( -- flag ) state @ 0<> ;
   : enter-compilation ( -- )  ] ;
   : leave-compilation ( -- )  postpone [ ;


[...]

> As for "there may be", Chuck Moore said "Don't speculate".  Of course
> Moore does not care about APIs and would eliminate the user variable
> BASE and do something else as soon as he sees a more advantageous way,
> and he has done so for STATE (which is probably the reason why we have
> the restriction on STATE despite not allowing the polyForth approach
> to compilation mode), so his opinion may not be that relevant when
> designing an API.  But still, of the three examples you mentioned:
> 
> BASE: I thought about one reason where being able to catch a change to
> BASE would have been advantageous, but found a way to work without
> that capability, probably with little cost.


I would like to ensure that the number-conversion radix is withing the 
valid range. Using a setter, I could have:

   : set-base ( u1 -- ) \ u1 shall be in {{2...36}}
     dup 2 37 within if _base ! exit then
     -12 throw \ "argument type mismatch"
   ;


> 
> STATE: We already have setters for that, and we have not found that to
> be a significant advantage.

At the very least, the setters allow different implementations, and this 
is a significant advantage. Due to absent of a proper getter, they have 
to also update `STATE`.



> >IN: The word that probably uses >IN most often is PARSE-NAME, so
> let's take a look:
> 
> In Gforth PARSE-NAME is a deferred word, and by default it contains:
> 
> : (name) ( -- c-addr count )
>      source 2dup >r >r >in @ 2dup u< IF  -18 throw  THEN
>      /string (parse-white)
>      2dup input-lexeme!
>      2dup + r> - 1+ r> min >in ! ;
> 
> I see a number of optimizations that could be done if we could hang
> actions on to the writing and reading of >IN, e.g., have a 2variable
> rest-source, and implement (name) like this:
> 
> : (name) ( -- c-addr count )
>    rest-source 2@ (parse-white) 2dup input-lexeme!
>    dup if 1/string then rest-source 2! ;
> 
> with corresponding extra work when setting and getting >IN, and in
> SOURCE and maybe elsewhere.
> 
> Would this buy much?  One would have to measure it, but at least for
> the things I have done, the parsing speed never has been a problem.


Again, with a setter we could check whether the input value is valid.
Also, having a getter, one could easily virtualize `source` and `refill` [1]

I now use `set-source-offset ( u -- )` and `source-offset ( -- u )`, 
which can be defined as follows:

   : set-source-offset ( u -- )
     source nip over u< invert if >in ! exit then
     -18 throw \ "parsed string overflow"
   ;
   : source-offset ( -- u )
     >in @
   ;


[1] <https://forth-standard.org/standard/core/PARSE#reply-428>
The idea of this approach is that you do not need to break input text 
from a file into lines (and so you can avoid double scanning the same 
input text). You can provide a line only when it is requested by 
`source` or `source-offset`.



>> However, the general objection against variables in an API is that they
>> do not allow a system (or a wrapper) to have additional actions that are
>> performed when getting or setting the value.
>>
>> This objection also applies to the words created using `value` and
>> `defer` (perhaps to a lesser extent in complex systems like Gforth, but
>> fully so regarding simpler systems and programs/wrappers).
> 
> The use of getters and setters is the mark of complex systems such as
> those programmed in C++ and Java, so I doubt that simple Forth systems
> would move complexity into SET->IN, GET->IN, SOURCE etc. in order to
> make PARSE-NAME faster.

There are other reasons except making `parse-name` faster.

Concerning complexity. We already have:
   - `get-current` and `set-current`
   - `get-order` and `set-order`
   - `precision` and `set-precision`

The use of these getters and setters is not a mark of complexity.


Regarding naming. I prefer to name getters without leading "get-", see 
rationale in [2]; in Forth-94, "get-" was added in two cases only due to 
conflicts.

[2] "Naming convention for setter and getter"
<https://github.com/ForthHub/discussion/discussions/137>



> For the more sophisticated systems, value-flavoured and
> defer-flavoured words can be implemented to allow hanging additional
> actions onto the setting and getting.  And I think that this is the
> way to go, given the preference towards value-flavoured words shown in
> recent years by, e.g., Joerg Voelker and Nick Nelson.

I don't think this is a way to go for APIs, because `to`-based methods 
cannot be wrapped in a standard way.


--
Ruvim

[toc] | [prev] | [next] | [standalone]

#135192 — Re: Setters and getters in APIs (was: Recognizer API v.2025-09-11)

Ruvim <ruvim.pinka@gmail.com> writes:
>In general, setters allow us to enforce rules before updating the value; 
>also, they allows us to change the internal implementation, without 
>breaking code that depends on the API. Getters allow us calculate a 
>value only when it is needed, rather than storing it explicitly.

All these features can be had with value-flavoured words, too.

>> Ruvim <ruvim.pinka@gmail.com> writes:
>>> On 2026-06-15 17:17, Anton Ertl wrote:
>> A standard program cannot change how # is implemented, either, so
>> having a standard SET-BASE would not help for the purpose I outlined
>> above.
>
>However, a standard program could redefine `set-base` and the words for 
>pictured numeric output, such as `#`, `#s` (as well as others required 
>for the program's purposes).

Yes, one can replace all the numeric output words with new versions,
but who is going to do that?

Anyway, assuming someone will do it, they can do it under any word
names, whether it's the names of the standard words or some other
names.

So the advantage of having a standard SET-BASE in this unrealistic
scenario would be that you can now define your own SET-BASE and
friends, and the result would still be a standard system.  Given that
the scenario is not particularly realistic, not a signicant advantage.

Even with the current standard, you can do


: get-base ... ; \ or define a value-flavoured BASE@
: set-base ... ; \ or define TO BASE@
: # ... ;
...
: base -13 throw ; immediate \ prevent direct access to BASE

and you get pretty much the result you want.  For a word that is more
popular than BASE, this would not work that well.

>There is also a similar, yet more compelling counter-argument:
>If a standard `SET-BASE` setter existed, then *both* system implementors 
>and program authors could easily implement/use this method for 
>optimization or other purposes;

Easily?  I don't consider redefining all the numeric output and input
stack to be easy.

>> Another take on your statements is to think about standardizing
>> SET-TO.  For now, though, I don't think that there is enough common
>> practice.
>
>I don't feel the lack of such a method.

We felt it, that's why it's a documented feature of development
Gforth.

>And I don't see any advantages of `TO BASE` over `SET-BASE` in terms of 
>*usage*.

>The advantage of `SET-BASE` is that it can be easily redefined, allowing 
>the program/wrapper to add additional actions in a standard way.

Actually not, because the redefinition only affects the uses of
SET-BASE after the redefinition.  So your "easily" means redefining
the complete stack of words that recursively depend on SET-BASE.

For TO BASE@, things would be similar.

So if you want to be sure you can change things later, you probably
should define a deferred word SET-BASE-HOOK (or TO-BASE@-HOOK) or
somesuch, where you plug in your additional actions.

>At the very least, the setters allow different implementations, and this 
>is a significant advantage.

It has turned out that it is not a significant advantage, and the
restriction not to use STATE ! has been an encumbrance.

>> >IN: The word that probably uses >IN most often is PARSE-NAME, so
>> let's take a look:
>> 
>> In Gforth PARSE-NAME is a deferred word, and by default it contains:
>> 
>> : (name) ( -- c-addr count )
>>      source 2dup >r >r >in @ 2dup u< IF  -18 throw  THEN
>>      /string (parse-white)
>>      2dup input-lexeme!
>>      2dup + r> - 1+ r> min >in ! ;
>> 
>> I see a number of optimizations that could be done if we could hang
>> actions on to the writing and reading of >IN, e.g., have a 2variable
>> rest-source, and implement (name) like this:
>> 
>> : (name) ( -- c-addr count )
>>    rest-source 2@ (parse-white) 2dup input-lexeme!
>>    dup if 1/string then rest-source 2! ;
>> 
>> with corresponding extra work when setting and getting >IN, and in
>> SOURCE and maybe elsewhere.
>> 
>> Would this buy much?  One would have to measure it, but at least for
>> the things I have done, the parsing speed never has been a problem.
>
>
>Again, with a setter we could check whether the input value is valid.

It is checked now in the parsing words.  With a setter, that would be
more concentrated and any mistake would show up where it happens, so
this is an advantage.  In practice, I have not experienced errors in
setting >IN.

>Also, having a getter, one could easily virtualize `source` and `refill` [1]
...
>[1] <https://forth-standard.org/standard/core/PARSE#reply-428>
>The idea of this approach is that you do not need to break input text 
>from a file into lines (and so you can avoid double scanning the same 
>input text). You can provide a line only when it is requested by 
>`source` or `source-offset`.

SOURCE and REFILL can be implemented like you suggest and
"virtualized" already.  They do not depend on how >IN is read or
written.  In Gforth, SOURCE and REFILL are methods of the input-stream
class.

>Concerning complexity. We already have:
>   - `get-current` and `set-current`
>   - `get-order` and `set-order`
>   - `precision` and `set-precision`
>
>The use of these getters and setters is not a mark of complexity.

If you don't use them for the purpose of complexifying the program,
they are pointless.

In my experience all these words are pointless, in particular the
...-CURRENT and PRECISION words.

I have considered a more complex, but faster implementation of the
search order that would hook into SET-ORDER such that changes to the
search order would also change the internal data structures of the
search order, but until now the search order speed has not been enough
of an issue to justify the complexity.

>I don't think this is a way to go for APIs, because `to`-based methods 
>cannot be wrapped in a standard way.

That can be fixed.

- 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 2026 CFP: http://www.euroforth.org/ef26/cfp.html

[toc] | [prev] | [next] | [standalone]

#135139 — Re: non-parsing `TO` considered harmful

On 6 Jun 2026 at 18:17:24 CEST, "Anton Ertl" <Anton Ertl> wrote:

> Ruvim <ruvim.pinka@gmail.com> writes:
>>> Here is an example of a program that relies on a parsing `to`, but is
>>> not compliant due to that very ambiguous condition regarding `postpone`.
>>> Let's introduce a multiple assignment construct of the following form:
>>> `1 2 3  to( a b c )`.
>>> 
>>> 
>>>    : ?comp ( -- ) state @ if exit then -14 throw ;
>>> 
>>>    : equals ( sd2 sd1 -- flag )
>>>      dup 3 pick <> if 2drop 2drop false exit then
>>>      compare 0=
>>>    ;
>>>    : source-offset ( -- u )
>>>> in @
>>>    ;
>>>    : set-source-offset ( u -- )
>>>      source nip over u<invert if >in ! exit then
>>>      -18 throw \ "parsed string overflow"
>>>    ;
>>> 
>>>    synonym take-lexeme-maybe parse-name
>>> 
>>>    : take-lexeme ( "ccc" -- sd )
>>>      take-lexeme-maybe dup if exit then -16 throw
>>>    ;
>>> 
>>>    : to( ( "ccc<rparen>" -- ) \ " a b c )"
>>>      ?comp  source-offset ( u.offset )
>>>      take-lexeme s" )" equals if drop exit then
>>>      ( u.offset ) recurse ( u.offset )
>>>      source-offset  swap set-source-offset
>>>        postpone to
>>>      set-source-offset
>>>    ; immediate
>>> 
>>>    \ usage example
>>> 
>>>    0 value a
>>>    0 value b
>>> 
>>>    : init-foo ( -- ) 2 3  to( a b ) ;
>>> 
>>>    init-foo  a . b .  \ it should print "2 3"
>> 
>> 
>> 
>> Do you know a Forth system in which `to` parses the parse area and in
>> which the definition for `to(` given above *does not* work?
> 
> Depending on what you mean by "work".  Anything that contains ?COMP is
> deficient by design.
> 
>> How do you implement a construct `to( ... )` that works both in
>> interpretation state and in compilation state?
> 
> I don't.  As for how someone else could do it, see below.
> 
>> Also, we could replace `postpone to` with
>>   `state @ if  postpone to  else  ['] to execute  then`
> 
> Also deficient by design.
> 
>> Interestingly, the Recognizer API does not help in implementing this
>> construct.
> 
> One way would be to add an immediate word TO( that changes rec-forth
> (the default recognizer sequence; damn renamings) to a special
> recognizer.  This special recognizer just pushes every string it
> should recognizer to a TO(-stack, except when it recognizes ")".
> 
> When it recognizes ")", it restores the original REC-FORTH, takes the
> top string "<word>" off the TO(-stack, constructs a string "TO
> <word>", and EVALUATEs it (you may try to take precautions such that
> the right TO is found, but the standard gives us little to play with
> here).  Repeat until the TI(-stack is empty.  Not even non-standard
> POSTPONE TO is needed, and it also works with non-parsing TO
> implementations.  It does not work if the user has defined TO to mean
> something else (the curse of EVALUATE).
> 
> However, instead of going for recognizers, you might play the same
> trick by letting TO( parse the strings up to ")" and push them on the
> TO(-stack.  And that's simpler to implement, so yes, the recognizer
> API does not help here.
> 
> But then recognizers are not designed for more than a word (the string
> recognizer is already a stretch).  So what Gforth has is a REC-TO that
> recognizes "-><word>".
> 
> So here's the implementation (untested):
> 
> : to(
>   0 0 2>r begin
>      parse-name dup 0= abort" unfinished TO("
>      2dup 2>r
>      s" )" str= until
>   2r> 2drop \ get rid of ")"
>   begin
>      2r> dup while
>          [: "to " type ;] >string-execute evaluate
>          \ freeing the strings is left as exercise to the reader
>   repeat
>   2drop \ get rid of 0 0
> ; immediate
> 
> Gforth has an API for defing words with user-defined TO
> <https://net2o.de/gforth/Words-with-user_002ddefined-TO-etc_002e.html>,
> but there is currently no proper API for defining words that perform
> the function of TO or one of its siblings (+TO etc), in particular
> there is no API that would support a user-defined REC-TO or TO(.  This
> shows in using internal words like TO-SLOTS in REC-TO.
> 
> Given the large differences between TO implementations in systems, I
> expect that we will have a hard time (as in: it won't happen)
> standardizing TO-related APIs.
> 
> - anton

Surely this only serves to demonstrate that recognisers are not the answer
to all maidens' prayers.

Stephen
-- 
Stephen Pelc, stephen@vfxforth.com
Wodni & Pelc GmbH
Vienna, Austria
Tel: +44 (0)7803 903612, +34 649 662 974
http://www.vfxforth.com/downloads/VfxCommunity/
  free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#135143 — Re: non-parsing `TO` considered harmful

Stephen Pelc <stephen@vfxforth.com> writes:
>Surely this only serves to demonstrate that recognisers are not the answer
>to all maidens' prayers.

I have no idea what all maidens pray for, but this very much has the
smell of a straw-man argument.

- 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 2025 proceedings: http://www.euroforth.org/ef25/papers/

[toc] | [prev] | [next] | [standalone]

#134897

On 7 Apr 2026 at 21:55:37 CEST, "Gerry Jackson" <do-not-use@swldwa.uk> wrote:

> On 07/04/2026 12:35, albert@spenarnc.xs4all.nl wrote:
>> A similar situation applies to "TO must scan". It turns out there
>> is no standard program that can detect this. It steers implementation
>> towards a scanning TO.
> 
> On the contrary, Ruvim posted some code that is a standard program and
> which distinguises between a parsing TO and one that sets a flag for a
> following VALUE to act on.

VFX sets a flag for TO and friends and has done so for 30+ years. We have no
intention of changing despite the cleverness of Ruvim's detection scheme. We
take the "as if" position because
  a) it simplifies implementation.
  b) no user has complained.

Stephen
-- 
Stephen Pelc, stephen@vfxforth.com
Wodni & Pelc GmbH
Vienna, Austria
Tel: +44 (0)7803 903612, +34 649 662 974
http://www.vfxforth.com/downloads/VfxCommunity/
  free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#135129 — non-parsing `TO` considered harmful

On 2026-04-09 10:12, Stephen Pelc wrote:
> On 7 Apr 2026 at 21:55:37 CEST, "Gerry Jackson" <do-not-use@swldwa.uk> wrote:
> 
>> On 07/04/2026 12:35, albert@spenarnc.xs4all.nl wrote:
>>> A similar situation applies to "TO must scan". It turns out there
>>> is no standard program that can detect this. It steers implementation
>>> towards a scanning TO.
>>
>> On the contrary, Ruvim posted some code that is a standard program and
>> which distinguises between a parsing TO and one that sets a flag for a
>> following VALUE to act on.
> 
> VFX sets a flag for TO and friends and has done so for 30+ years. We have no
> intention of changing despite the cleverness of Ruvim's detection scheme. We
> take the "as if" position because
>    a) it simplifies implementation.
>    b) no user has complained.

As far as I can see, this approach does not simplify implementation to 
any significant extent; instead, it limits the use cases. In VFX, it 
also brakes `find` for `to` and other similar words. As a user, I would 
complain.


To ensure that all operators in VfxForth parse the parse area for their 
immediate argument, it suffices to modify the word `operator` as follows:

   : take-name>xt ( "ccc" -- xt )
     bl word find ?undef
   ;
   : translate-xt ( any xt -- any )
     state @ if  compile,  else  execute  then
   ;
   : operator      \ n -- ; define an operator
     create
       here  swap ,  OperatorChain @ ,  OperatorChain !
       immediate
     does> @ OperatorType !
       take-name>xt translate-xt
   ;


This also makes `find` correctly works for `to` and other similar words.


> 
> Stephen

--
Ruvim

[toc] | [prev] | [next] | [standalone]

#135132 — VFX Forth problems

On 2026-06-04 22:30, Ruvim wrote:
> On 2026-04-09 10:12, Stephen Pelc wrote:
>> On 7 Apr 2026 at 21:55:37 CEST, "Gerry Jackson" <do-not-use@swldwa.uk> 
>> wrote:
>>
>>> On 07/04/2026 12:35, albert@spenarnc.xs4all.nl wrote:
>>>> A similar situation applies to "TO must scan". It turns out there
>>>> is no standard program that can detect this. It steers implementation
>>>> towards a scanning TO.
>>>
>>> On the contrary, Ruvim posted some code that is a standard program and
>>> which distinguises between a parsing TO and one that sets a flag for a
>>> following VALUE to act on.
>>
>> VFX sets a flag for TO and friends and has done so for 30+ years. We 
>> have no
>> intention of changing despite the cleverness of Ruvim's detection 
>> scheme. We
>> take the "as if" position because
>>    a) it simplifies implementation.
>>    b) no user has complained.
> 
> As far as I can see, this approach does not simplify implementation to 
> any significant extent; instead, it limits the use cases. In VFX, it 
> also brakes `find` for `to` and other similar words. As a user, I would 
> complain.
> 
> 
> To ensure that all operators in VfxForth parse the parse area for their 
> immediate argument, it suffices to modify the word `operator` as follows:
> 
>    : take-name>xt ( "ccc" -- xt )
>      bl word find ?undef
>    ;
>    : translate-xt ( any xt -- any )
>      state @ if  compile,  else  execute  then
>    ;
>    : operator      \ n -- ; define an operator
>      create
>        here  swap ,  OperatorChain @ ,  OperatorChain !
>        immediate
>      does> @ OperatorType !
>        take-name>xt translate-xt
>    ;
> 
> 
> This also makes `find` correctly works for `to` and other similar words.
> 


In VFX Forth 5.43, the above implementation still does not work for an 
immediate value (a child of `value` marked as immediate), because 
`compile,` is broken for immediate words.

Namely, `compile,` executes xt of an immediate word, instead of compile 
it. Thus, the following test fails:
   t{ : [foo] 0 ; immediate -> }t
   t{ :noname [ 1 ' [foo] compile, ?dup nip ] literal ; execute -> 0 1 }t

In VFX, the last line results to ( 0 ) instead of ( 0 1 ).

Even if we fix this problem, there is another one. In VFX, each child of 
`value` has its own compiler, and when a child of `value` is made 
immediate, its compiler xt is *replaced* with an xt that performs the 
*interpretation semantics* for that child.

This is a design flaw to use the same slot for both: a helper definition 
that performs compilation with optimizations, and a helper definition 
that performs non-default compilation semantics.

A possible approach is to associate an optimizer with xt, and a helper 
for non-default compilation semantics with nt.


--
Ruvim

[toc] | [prev] | [next] | [standalone]

#135228

On 4/9/2026 12:12 PM, Stephen Pelc wrote:
> On 7 Apr 2026 at 21:55:37 CEST, "Gerry Jackson" <do-not-use@swldwa.uk> wrote:
> 
>> On 07/04/2026 12:35, albert@spenarnc.xs4all.nl wrote:
>>> A similar situation applies to "TO must scan". It turns out there
>>> is no standard program that can detect this. It steers implementation
>>> towards a scanning TO.
>>
>> On the contrary, Ruvim posted some code that is a standard program and
>> which distinguises between a parsing TO and one that sets a flag for a
>> following VALUE to act on.
> 
> VFX sets a flag for TO and friends and has done so for 30+ years. We have no
> intention of changing despite the cleverness of Ruvim's detection scheme. We
> take the "as if" position because
>    a) it simplifies implementation.
>    b) no user has complained.
> 
> Stephen

Agreed. My Forths have used TO since 1983 (concept derived from FysForth).

[toc] | [prev] | [next] | [standalone]

#135230

marcel hendrix <mhx@iae.nl> wrote:
> On 4/9/2026 12:12 PM, Stephen Pelc wrote:
>> On 7 Apr 2026 at 21:55:37 CEST, "Gerry Jackson" <do-not-use@swldwa.uk> wrote:
>>
>>> On 07/04/2026 12:35, albert@spenarnc.xs4all.nl wrote:
>>>> A similar situation applies to "TO must scan". It turns out there
>>>> is no standard program that can detect this. It steers implementation
>>>> towards a scanning TO.
>>>
>>> On the contrary, Ruvim posted some code that is a standard program and
>>> which distinguishes between a parsing TO and one that sets a flag for a
>>> following VALUE to act on.
>>
>> VFX sets a flag for TO and friends and has done so for 30+ years. We have no
>> intention of changing despite the cleverness of Ruvim's detection scheme. We
>> take the "as if" position because
>>    a) it simplifies implementation.
>>    b) no user has complained.
>>
>> Stephen
>
> Agreed. My Forths have used TO since 1983 (concept derived from FysForth).

Same here. ciforth means not alone "computer intelligence forth" it also
means "close to iso" forth. Ignoring the requirement of parsing is
inconsequential for the users, not worth complicating the implementation
over.
Groetjes Albert
--
The glass is half empty. There is no such thing as a free world.
This is the first day of the end of your life.
If you can't beat them, ... too bad.

[toc] | [prev] | [next] | [standalone]

#135138

On 7 Apr 2026 at 21:55:37 CEST, "Gerry Jackson" <do-not-use@swldwa.uk> wrote:

> On 07/04/2026 12:35, albert@spenarnc.xs4all.nl wrote:
>> A similar situation applies to "TO must scan". It turns out there
>> is no standard program that can detect this. It steers implementation
>> towards a scanning TO.
> 
> On the contrary, Ruvim posted some code that is a standard program and
> which distinguises between a parsing TO and one that sets a flag for a
> following VALUE to act on.
> 
> I can't find the post but the gist of it was (I think):
> 
> 1 value v1
> 2 value v2 immediate
> : test  to v2 v1  ;
> Running test with
> 3 test
> A parsing TO will set v2 to 3
> A flagging TO will execute v2 during compilation of test because it is
> immediate. So test will set v1 to 3 leaving v2 unchanged.

The test depends on being able to define V2 as IMMEDIATE. Where in the
standard does
it specify that children on VALUE are not IMMEDIATE ? If does so specify, then
the
test is implementation dependent, and contradicts the intention of the
standard.

Be careful what you wish for.

VFX and its predecessor ProForth have used a flagging TO for well over 30
years and
I am not breaking the world's largest Forth application (32 bit, over 30 Mb
binary) for a
language lawyer and a probably invalid test.

Stephen
-- 
Stephen Pelc, stephen@vfxforth.com
Wodni & Pelc GmbH
Vienna, Austria
Tel: +44 (0)7803 903612, +34 649 662 974
http://www.vfxforth.com/downloads/VfxCommunity/
  free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#135141 — non-parsing `TO` considered harmful (was: Coroutines in Forth)

On 2026-06-07 11:53, Stephen Pelc wrote:
> On 7 Apr 2026 at 21:55:37 CEST, "Gerry Jackson" <do-not-use@swldwa.uk> wrote:
> 
>> On 07/04/2026 12:35, albert@spenarnc.xs4all.nl wrote:
>>> A similar situation applies to "TO must scan". It turns out there
>>> is no standard program that can detect this. It steers implementation
>>> towards a scanning TO.
>>
>> On the contrary, Ruvim posted some code that is a standard program and
>> which distinguises between a parsing TO and one that sets a flag for a
>> following VALUE to act on.
>>
>> I can't find the post but the gist of it was (I think):
>>
>> 1 value v1
>> 2 value v2 immediate
>> : test  to v2 v1  ;
>> Running test with
>> 3 test
>> A parsing TO will set v2 to 3
>> A flagging TO will execute v2 during compilation of test because it is
>> immediate. So test will set v1 to 3 leaving v2 unchanged.
> 
> The test depends on being able to define V2 as IMMEDIATE. 

In a standard Forth system, a child of `value`, as well as *any* 
user-defined named definition (with the exception of `synonym` 
children), can be made immediate. A child of synonym inherits immediacy 
from its original word.

<https://forth-standard.org/standard/core/IMMEDIATE>


> Where in the standard does it specify that children on VALUE are not IMMEDIATE ?

It is specified in the glossary entry 6.2.2405 VALUE
<https://forth-standard.org/standard/core/VALUE>

Namely, it specifies "_name_ Execution", where _name_ is a child of 
`value`. And it does not specify the compilation semantics in 
"Compilation:" section.

Therefore, we apply 3.4.3.3 Compilation semantics:
<https://forth-standard.org/standard/usage#usage:compile>

   | Unless otherwise specified in a "Compilation:" section
   | of the glossary entry, the compilation semantics
   | of a Forth definition shall be to append
   | its execution semantics to the execution semantics
   | of the current definition.

Thus, a word created by `value` is not an immediate word unless the user 
applies `immediate` to it.

This does not prevent us from performing any optimizations when adding 
the execution semantics of a `value` child to the current definition.



> If does so specify, then the test is implementation dependent,
> and contradicts the intention of the standard.
> 
> Be careful what you wish for.
> 
> VFX and its predecessor ProForth have used a flagging TO for well over 30
> years and I am not breaking the world's largest Forth application
> (32 bit, over 30 Mb binary) for a language lawyer and a probably invalid test.


I would like to check whether such a change in `to` and `value` will 
brake this application.


In any case, nothing prevents VfxForth from providing such a `value` 
word whose children cannot be made immediate. However, this should be 
documented, without passing off such a `value` as a standard word.

Ditto for the provided word `to`, which is not a parsing word (whereas 
the standard `to` is required to perform parsing).



--
Ruvim

[toc] | [prev] | [next] | [standalone]

#135470 — Re: non-parsing `TO` considered harmful

On 6/7/26 8:31 AM, Ruvim wrote:
> On 2026-06-07 11:53, Stephen Pelc wrote:
>> On 7 Apr 2026 at 21:55:37 CEST, "Gerry Jackson" <do-not-use@swldwa.uk> 
>> wrote:
>>
>>> On 07/04/2026 12:35, albert@spenarnc.xs4all.nl wrote:
>>>> A similar situation applies to "TO must scan". It turns out there
>>>> is no standard program that can detect this. It steers implementation
>>>> towards a scanning TO.
>>>
>>> On the contrary, Ruvim posted some code that is a standard program and
>>> which distinguises between a parsing TO and one that sets a flag for a
>>> following VALUE to act on.
>>>
>>> I can't find the post but the gist of it was (I think):
>>>
>>> 1 value v1
>>> 2 value v2 immediate
>>> : test  to v2 v1  ;
>>> Running test with
>>> 3 test
>>> A parsing TO will set v2 to 3
>>> A flagging TO will execute v2 during compilation of test because it is
>>> immediate. So test will set v1 to 3 leaving v2 unchanged.
>>
>> The test depends on being able to define V2 as IMMEDIATE. 
> 
> In a standard Forth system, a child of `value`, as well as *any* user- 
> defined named definition (with the exception of `synonym` children), can 
> be made immediate. A child of synonym inherits immediacy from its 
> original word.
> 
> <https://forth-standard.org/standard/core/IMMEDIATE>

In zeptoforth at least there is no way to define new immediate words
other than colon definitions for the reason that [IMMEDIATE] needs to
be called (or IMMEDIATE needs to be called from within a defining word)
before ; is called because zeptoforth is designed to be capable of
compiling to flash, and once words are written to flash they are written
to flash and they cannot be mutated afterwards (aside from mass flash
erasure).

New words to specifically create immediate CONSTANT's or like could be
created but I have never had the need to do so; if someone needs an
immediate CONSTANT they could use the following:

: CONSTANT-IMMEDIATE { x }
   : IMMEDIATE X POSTPONE LITERAL POSTPONE ;
;
: 2CONSTANT-IMMEDIATE { x y }
   : IMMEDIATE X POSTPONE LITERAL Y POSTPONE LITERAL POSTPONE ;
;

Of course, zeptoforth is not a standard Forth system, and for the most 
part does not attempt to be one.

>> Where in the standard does it specify that children on VALUE are not 
>> IMMEDIATE ?
> 
> It is specified in the glossary entry 6.2.2405 VALUE
> <https://forth-standard.org/standard/core/VALUE>
> 
> Namely, it specifies "_name_ Execution", where _name_ is a child of 
> `value`. And it does not specify the compilation semantics in 
> "Compilation:" section.
> 
> Therefore, we apply 3.4.3.3 Compilation semantics:
> <https://forth-standard.org/standard/usage#usage:compile>
> 
>    | Unless otherwise specified in a "Compilation:" section
>    | of the glossary entry, the compilation semantics
>    | of a Forth definition shall be to append
>    | its execution semantics to the execution semantics
>    | of the current definition.
> 
> Thus, a word created by `value` is not an immediate word unless the user 
> applies `immediate` to it.
> 
> This does not prevent us from performing any optimizations when adding 
> the execution semantics of a `value` child to the current definition.

If I made a way to make immediate VALUE's or 2VALUE's in zeptoforth 
(e.g. I created a word VALUE-IMMEDIATE), I would expect the following 
behavior:

1 VALUE FOO
2 VALUE-IMMEDIATE BAR
: FOOBAR 3 TO BAR FOO ; \ This is cromulent
FOO . \ prints 1  ok
BAR . \ prints 2  ok
FOOBAR . \ prints 1  ok
FOO . \ prints 1  ok
BAR . \ prints 3  ok

>> If does so specify, then the test is implementation dependent,
>> and contradicts the intention of the standard.
>>
>> Be careful what you wish for.
>>
>> VFX and its predecessor ProForth have used a flagging TO for well over 30
>> years and I am not breaking the world's largest Forth application
>> (32 bit, over 30 Mb binary) for a language lawyer and a probably 
>> invalid test.
> 
> 
> I would like to check whether such a change in `to` and `value` will 
> brake this application.
> 
> 
> In any case, nothing prevents VfxForth from providing such a `value` 
> word whose children cannot be made immediate. However, this should be 
> documented, without passing off such a `value` as a standard word.
> 
> Ditto for the provided word `to`, which is not a parsing word (whereas 
> the standard `to` is required to perform parsing).

In my own case I implement TO as a parsing word. TO parses a token, then 
first looks up in the local variable stack whether the token is a local 
variable (provided a compiling state), and then compiles code to pop the 
TOS (and that directly below it if the local variable is double-cell) 
and set that local variable to that. If no such local variable is 
available within the current local scope, then it attempts to find a 
word with that same name. If a word exists, and it is a valid VALUE or 
2VALUE, it then compiles code to pop the TOS (and that directly below it 
if it is a 2VALUE) and set the VALUE or 2VALUE's compiled location in 
RAM to it.

Travis

[toc] | [prev] | [next] | [standalone]

Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7  Next page →

Back to top | Article view | comp.lang.forth

csiph-web