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: <a1aab44ee3b1b56c2f54f2606e98d040@www.novabbs.com> <23a44aa0445a30c0fc782819f48463f9@www.novabbs.com> <nnd$685d2a62$7d072f38@c2a291bc8c0eb1cd> <v8nrb0$3vbpv$3@dont-email.me> <nnd$4ced6d91$68fcde58@19347b2874c81786> <v8qnhv$n39d$1@dont-email.me>
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 <ruvim.pinka@gmail.com> writes:
>On 2024-08-05 14:04, albert@spenarnc.xs4all.nl wrote:
>> In article <v8nrb0$3vbpv$3@dont-email.me>,
>> Ruvim  <ruvim.pinka@gmail.com> 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