Re: Alternative for long parsing words

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 -