Alternative for long parsing words (was: VALUE and TO implementation)

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

In article <23a44aa0445a30c0fc782819f48463f9@www.novabbs.com>,
mhx <mhx@iae.nl> wrote:

However, as I showed earlier, a parsing "TO" has several advantages over
a non-parsing "TO".

>
Am I the only one that thinks parsing words are an incredible nuisance?

 Numbers (denotations) must be parsed. Otherwise I do think parsing
words is a nuisance.
I might tolerate an exception with
"FILENAME" INCLUDED
"FILESNAME" NEEDED
"WORDNAME" WANTED
to be supplemented with
INCLUDE FILENAME
NEED  FILESNAME
WANT WORDNAME
Merely for convenience to not type double quotes that are
far from the hand position, and even have different position
on the keyboard. And only in interactive sessions.
 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
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?

If you want separate behaviours in some mode, they must be arrived
at via the dea.
 

Agreed.
But simplicity of the dual-nt approach (like in cmForth) is sometimes preferable. Because compilation semantics for a word are defined as an ordinary word.
--
Ruvim