Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: anton@mips.complang.tuwien.ac.at (Anton Ertl) Newsgroups: comp.lang.forth Subject: Re: Alternative for long parsing words Date: Mon, 05 Aug 2024 14:33:10 GMT Organization: Institut fuer Computersprachen, Technische Universitaet Wien Lines: 73 Message-ID: <2024Aug5.163310@mips.complang.tuwien.ac.at> References: <23a44aa0445a30c0fc782819f48463f9@www.novabbs.com> Injection-Date: Mon, 05 Aug 2024 17:17:54 +0200 (CEST) Injection-Info: dont-email.me; posting-host="a52fae917b2b8ed2b91ac6592ac1a3e3"; logging-data="863113"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/8lJsbwhY4BSGapU+g7Kax" Cancel-Lock: sha1:Jqxc55i6/TxnrLgmDK8kx207Xrc= X-newsreader: xrn 10.11 Bytes: 3890 Ruvim writes: >On 2024-08-05 14:04, albert@spenarnc.xs4all.nl wrote: >> In article , >> Ruvim wrote: >>> But if you hate parsing words in principle (just because they do >>> parsing), why not hate such long parsing words like `[if]`, `\`, the >>> construct "]]...[[", etc? What is an alternative for them? .... >I meant the word `[IF]` by itself, without connection with `WANT`. Not necessarily a parsing word. Could also be treated as something like another state (i.e., the text interpreter does the parsing, but does something different with the words than interpretation state or compile state. In every case, the interaction with other features is problematic; e.g., consider: 0 [IF] .... \ .... \ [ELSE] \ .... cr .( you should see this according to the standard) [THEN] (and the systems I tested actually comply with the standard requirements) This behaviour might surprise users, especially in connection with nested [IF]s. However, there have been few complaints, so it obviously is only a minor issue. \ parses, but apart from interactions like above it looks fine to me. >The word `]]` is also a parsing word (in a standard-compliant >implementation). You mean that implementing ]] as a standard program requires parsing. That's true, but the usual implementation in systems is as another state-like thing. And you also get interesting interactions if you combine it with [if], or parsing words like \ or (. The sequences inside ]]...[[ are short enough that this is rarely necessary, and if it is, you can do, e.g. ]] bla [[ ( x y ) ]] blub [[ instead of ]] bla ( x y ) blub [[ Not great, but has not been a significant issue yet. >How to implement such functionality without active parsing the input stream? How does :NONAME or ] implement its functionality? Do you also consider it a parsing word? Note that in some Forth, Inc. Forth systems ] parses on its own rather than using a state of the ordinary text interpreter. >But if such long parsing words like `[IF]` and `]]` are acceptable, why >the words that parses a single lexeme are not acceptable? (apart from >naming and terminator visibility problems)? A problem with parsing words like ' and ['] is that code using them usually cannot be copied and pasted between interpreted and compiled code. A problem with parsing words like S" is that implementing them properly requires mechanisms beyond what has been traditionally available. - anton -- M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html New standard: https://forth-standard.org/ EuroForth 2024: https://euro.theforth.net