Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #135136
| From | Ruvim <ruvim.pinka@gmail.com> |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: non-parsing `TO` considered harmful |
| Date | 2026-06-06 21:09 +0000 |
| Organization | A noiseless patient Spider |
| Message-ID | <110229l$23vm4$1@dont-email.me> (permalink) |
| References | (3 earlier) <10r3nfo$33464$1@dont-email.me> <nnd$1df5c626$6d97c61c@066801e65fcbf8a0> <10vsu39$neci$1@dont-email.me> <110159o$1rm6n$1@dont-email.me> <2026Jun6.181724@mips.complang.tuwien.ac.at> |
On 2026-06-06 16:17, 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".
By "does not work" I mean that the provided program does not behave as
specified in the usage example (a kind of test).
> Anything that contains ?COMP is deficient by design.
Do you mean that preventing accidentally execution of some word in
interpretation state (by throwing an exception) is deficient?
>> 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.
Do you mean an ambiguous condition on postponing and ticking `to`?
Otherwise, if you mean something other than applying `postpone` to
immediate words, please, clarify.
>> 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.
Agreed.
> 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
Thus, this implementation is more complex and unhygienic [2], and these
drawbacks are introduced solely for the sake of a few Forth systems that
provide non-standard `to`. The cost seems unjustified.
[2] It is unhygienic, as it requires `to` to be present in the context.
See: <https://en.wikipedia.org/wiki/Hygienic_macro>
>
> 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.
There could be a basic factor similar to `defer!`:
`execute-setter` Execution: ( any1 xt1 -- )
Set `xt1` to return `any1` on execution. An ambiguous condition exists
if `xt1` cannot be set to return `any1`.
`xt1` is the execution token of a word created with `value`, `2value`,
or `fvalue`.
> 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.
A side note: I think this is another argument against methods based on
`TO` or `IS` in the Recognizers API, and in APIs in general.
As far as I can see, all implementations that perform parsing (as
specified in the standard) meet the reasonable expectations.
But the implementations that do not perform parsing, vary in their
behavior. It is interesting to consider which other modern systems,
besides VfxForth, iForth, and ciForth, fall into this category.
In most Forth systems `to` is a parsing word:
<https://github.com/search?q=NOT+is%3Afork+language%3Aforth+%2F%28%5E%7C+%29%3A+to+%2F&type=code>
>
> - anton
--
Ruvim
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web