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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <v8qnhv$n39d$1@dont-email.me>, Ruvim <ruvim.pinka@gmail.com> wrote: >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:

On 2024-08-04 15:11, albert@spenarnc.xs4all.nl wrote:

Particularly I hate ' / ['] .
My solution that ' has to elevated to a denotation.
Meaning 'someword leave the address/dea/handle/nametoken
of `` someword '' that is the same in interpret and compile mode.

I also often use `'someword` instead of `['] someword` and `' someword`, >>> because I hate different forms for the conceptually same thing in
interpretation and compilation, and because the form `'someword` is shorter.

Another thing I hate is when it's not obvious that a word is a parsing
word, or what its delimiter. So I prefer when parsing delimiters are
visible.

For example, I would prefer:
want( word1 word2 word3 )
rather than:
want word1 want word2 want word3

I have changed WANT to accept several words on the same line
want word1 word2 word3
This is one of the few "improvements" I'm not sure about.
By itself WANT is a concession because it is actually
"word1" WANTED "word2" WANTED "word3" WANTED
Your proposal makes sense, having several WANT(ED) on the same line
is ugly and impractical, but parsing to the end of line is dubious.

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?

WANT is used recursively in blocks. If you wanted to accomplish the
same thing with [IF], it would be a horrid mess.

I meant the word `[IF]` by itself, without connection with `WANT`.

The word `[IF]` is a parsing word. If you hate parsing words in general,
what alternative to `[IF]` could you suggest?

The word `]]` is also a parsing word (in a standard-compliant >implementation). It parses the input stream till the lexeme "[[".

How to implement such functionality without active parsing the input stream?

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)?

Long story short:
I'm practical. I don't care for [IF] and I just copied from the
ANSI manual. I'm not dogmatic about it.
[IF] can be implemented by wordlists, relying on regular parsing
INTERPRET. I don't care for [IF] to implement that more elegant
method, and take on the burden of testing.
In my lisp efforts I have found that using INTERPRET recursively
can be very effective as long as you can switch the inputstream
easily. That makes EXECUTE-PARSING all but superfluous.

E.g. manx is an elaborate program running from windows32 to linux64.
There is only one [IF] to do tracing output, not used in a long time.
My reverse engineering assembler/disassembler is equally portable and
contains not a single [IF].
This is possible by using a library mechanism described above
WANTED.

Ruvim

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 6 Aug 2024 10:12:00 +0000, Ruvim wrote:
[..]

For example, in "C++":

/*

// /* comment */ puts("you should see this");
// the above command takes effect despite the line comment

/* other comment */

A rule of thumb: the one who gains control first wins.

One of the rare occasions where a colorizing text editor is
helpful.

-marcel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <v8ssth$1hnbh$1@dont-email.me>,
Ruvim <ruvim.pinka@gmail.com> wrote:

On 2024-08-05 18:33, Anton Ertl wrote:

Ruvim <ruvim.pinka@gmail.com> writes:

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.

This problem is not endemic to Forth. It takes place in many other >programming languages too.

For example, in "C++":

/*

// /* comment */ puts("you should see this");
// the above command takes effect despite the line comment

/* other comment */

A rule of thumb: the one who gains control first wins.

So you cannot read it unless you start parsing from the
very beginning.
The problem is that it becomes unreadable. Most people
who want to comment out sections that contains comment
are messy in other respects too. In my coding standards
there is the rule, that no nested comments are to be
saved in a source control system.
All commented out code is questionable. It shows that you
don't use your source control system properly.

In a language like Forth where everything can mean anything
it is good to have a comment sign \ that goes until the end
of the line.
If your editor can't do
123,456s/^/\\/
or some such, it is simply not powerful enough to serve
as a program editor.
(I have never used a folding editor, but probably it could
be used too.)

Ruvim

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <2024Aug5.163310@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:

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:

If PREFIX-es are present, this can be handled by a wordlist that
contains [IF] [THEN] [ELSE] and a PREFIX with an empty name.
The empty prefix matches everything, and is defined as a noop.
(Also handy in lisp to generate symbols that prior didn't exist)
Manipulating this wordlist in the proper way, all parsing is
handled in INTERPRET.

- anton

--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)