albert@cherry.(none) (albert) writes:
>Do you still use the recognizer/prefix & ?
>We were there first in 1993/2001 with that prefix.

Gforth has supported 'A in 0.2.1 (1996).

But that's water down the river. 'A' has been standardized.

>I would love to see 0X1A for hex

A number of systems support 0x1a, e.g., Gforth:

0x1a . 26 ok

It's just too annoying to have to replace the "0x" from gdb with "$".

>instead of $1A , freeing
>$HOME for environment variables.

In development Gforth:

require rec-env.fs ok
$HOME type /home/anton ok
$1a . 26 ok

No need for freeing. If you have an environment variable that would
be a valid hex number (my normal environment does not), you could
arrange for REC-ENV to be in front of REC-NUM (and write the hex
number with a leading 0), or write "ABC" getenv.

>That would be a beneficial c-compatibility.

C does not support $HOME, so why would that be any kind of
C-compatibility?

And is there any other criterion for "worst" and "beneficial" than
your personal preference?

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

On 29/05/2022 17:56, albert wrote:
> In article <t6t9mi$buj$2@dont-email.me>, Ruvim <ruvim.pinka@gmail.com> wrote:
>>On 2022-05-19 18:47, Anton Ertl wrote:
>>>> And after that, what to do with "[if]" and "[undefined]"?
>>>
>>> And \ and (.
>>
>>If they are with us in any case, we should not avoid them, but properly
>>(safely and readable) use them.
>
> I hate [UNDEFINED].
>
> "socket-server" [UNDEFINED] [IF]
> \ You really mean you can insert a portable definition of `socket-server?
> \ Even if you succeed, you uglifies you code beyond redemption.
> [THEN]
>
> has to be replaced by
>
> WANT socket-server

I don't care for its length but at least [UNDEFINED] is unambiguous.
Were shortness paramount I'd have chosen LACK. But hey, we need to
keep Forth respectable and starched shirts sell better.

On Sunday, May 29, 2022 at 6:18:12 PM UTC+2, dxforth wrote:
> > I hate [UNDEFINED].
> I don't care for its length but at least [UNDEFINED] is unambiguous.
> Were shortness paramount I'd have chosen LACK. But hey, we need to
> keep Forth respectable and starched shirts sell better.

I love [UNDEFINED] for the same reason I like

VARIABLE x
VALUE y
CONSTANT z
: a
CHAR b

You parse the thing, look it up in the symboltable and leave a 1 or a 0 - which [IF]
can pick up easily. Ok, you can discuss the name as far as I'm concerned, but that's
it.

I'd hate to see:

S" x" VARIABLE
20 S" y" VALUE
10 S" x" CONSTANT
S" a" DEF{ }
S" b" CHAR

Hans Bezemer

On 2022-05-29 20:18, dxforth wrote:
> On 29/05/2022 17:56, albert wrote:
>> In article <t6t9mi$buj$2@dont-email.me>, Ruvim <ruvim.pinka@gmail.com> wrote:
>>> On 2022-05-19 18:47, Anton Ertl wrote:
>>>>> And after that, what to do with "[if]" and "[undefined]"?
>>>>
>>>> And \ and (.
>>>
>>> If they are with us in any case, we should not avoid them, but properly
>>> (safely and readable) use them.

By "they" I don't mean these particular words, but porcelain words that
do parsing in general.

>>
>> I hate [UNDEFINED].
>>
>> "socket-server" [UNDEFINED] [IF]
>> \ You really mean you can insert a portable definition of `socket-server?
>> \ Even if you succeed, you uglifies you code beyond redemption.
>> [THEN]
>>
>> has to be replaced by
>>
>> WANT socket-server
>
> I don't care for its length but at least [UNDEFINED] is unambiguous.
> Were shortness paramount I'd have chosen LACK. But hey, we need to
> keep Forth respectable and starched shirts sell better.

lack( foo ) [if]
...
[then]

Nice!

Concerning compilation state, [lack]( foo ) looks overloaded.
So just use [ lack( foo ) ]

: bar
...
[ lack( foo ) ] [if]
...
[then]

[ glut( baz ) ] [if] \ "baz" is available
... baz
[then]
...
;

And to check availability of "foo" at run-time:

: foobar lack( foo ) if ... else ... then ;

--
Ruvim

On 2022-05-29 20:53, Hans Bezemer wrote:
> On Sunday, May 29, 2022 at 6:18:12 PM UTC+2, dxforth wrote:
>>> I hate [UNDEFINED].
>> I don't care for its length but at least [UNDEFINED] is unambiguous.
>> Were shortness paramount I'd have chosen LACK. But hey, we need to
>> keep Forth respectable and starched shirts sell better.
>
> I love [UNDEFINED] for the same reason I like
>
> VARIABLE x
> VALUE y
> CONSTANT z
> : a
> CHAR b
>
> You parse the thing, look it up in the symboltable and leave a 1 or a 0 - which [IF]
> can pick up easily. Ok, you can discuss the name as far as I'm concerned, but that's
> it.
>
> I'd hate to see:
>
> S" x" VARIABLE
> 20 S" y" VALUE
> 10 S" x" CONSTANT
> S" a" DEF{ }
> S" b" CHAR

But having shorter string literals it looks better:
"x" var
or
`x var
10 `x const

Anyway, what can you suggest if I need to create a definition (e.g. a
constant) programmatically, and its name is passed as an argument?

Having "const" from the above it could look as:

: foo ( sd.name -- ) ... 10 -rot const ... ;

--
Ruvim

On 2022-05-29 12:57, P Falth wrote:
> On Saturday, 28 May 2022 at 23:25:06 UTC+2, Ruvim wrote:
>> On 2022-05-29 00:34, P Falth wrote:
>>> On Saturday, 28 May 2022 at 18:41:48 UTC+2, Ruvim wrote:
>>>> On 2022-05-20 09:14, dxforth wrote:
>>
>>>>> A few may enjoy creating
>>>>> new parsing words (like the few that enjoy creating macros) but I wouldn't
>>>>> say either was intrinsic to Forth, or even popular. If creating new parsing
>>>>> words were popular, wouldn't there already be a convention for it?
>>>>>
>>>>> https://pastebin.com/qpZLFc6h
>>>>
>>>> The old convention was: don't use any special naming convention for
>>>> porcelain parsing word, they should look just like ordinary words.
>>>>
>>>> For example: "[COMPILE]" and ASCII in Forth-79, POSTPONE in Forth-94
>>>
>>> One of the first things that struck me when I learned about the forth language
>>> was the complete freedom to name words whatever you wanted.
>>> I do not want to change that!
>>> What you have presented might be very logical but it looks ugly and does not
>>> read well.
>> OK. Could you please order by ugliness (from higher to lower) the
>> following definitions for the word "ip-in-subnet ( x.ip x.ip-mask
>> x.ip-net -- flag )":
>
> This is how I would write it
>> : ip-in-subnet >r and r> = ;

This example is taken for simplicity. Instead, just take your real life
case when you pass an xt as an argument, or pass a word (or several) as
an immediate argument.

> This I can understand after looking up what dip does
>> : ip-in-subnet ['] and dip = ;
>
> The rest are just ugly and difficult to read. ' ´ ` all look the same for me at a quick view
>> : ip-in-subnet 'and dip = ; \ Tick is for quoting a word
>> : ip-in-subnet `and dip = ; \ Backtick is for quoting a word
>> : ip-in-subnet dip' and = ;
>> : ip-in-subnet dip:and = ;
>> : ip-in-subnet dip( and ) = ;
>> : ip-in-subnet dip{ and } = ;
>
> What I do not understand is this drive to pass an XT as argument.

No any xt is passed in the last four code examples.

> For sure it can be powerful in certain cases,
> but you do not need to rewrite everything in that style.

Actually, it's my position too.

Have a look [1], I started from a combinator (a word that accepts an xt
on the stack), and then introduced an equivalent parsing word:

| Now let's consider a variant of the "dip" combinator
| that accepts a word to be executed as an immediate argument
| and generates a more efficient code. Also, this variant can
| be better readable when the word is known in advance.

I provided two reasons for that:

1. Potentially, more efficient code.
2. Potentially, better readability.

In general, I talk not only about passing xt, but passing any argument
(for example, a name string).

Accepting immediate arguments can be a good choice in many cases. But a
common problem that authors don't mark these arguments in the source
code explicitly. And that worsens readability.

So for the words having immediate arguments — I want the boundaries of
these arguments be easy visible. And in the same time I want to have the
corresponding ("plumbing") words that accepts argument from the data
stack (or, reluctantly, a technique like "execute-parsing" at least).

[1] https://github.com/ForthHub/discussion/discussions/112

--
Ruvim

On Sunday, 29 May 2022 at 21:23:44 UTC+2, Ruvim wrote:
> On 2022-05-29 12:57, P Falth wrote:
> > On Saturday, 28 May 2022 at 23:25:06 UTC+2, Ruvim wrote:
> >> On 2022-05-29 00:34, P Falth wrote:
> >>> On Saturday, 28 May 2022 at 18:41:48 UTC+2, Ruvim wrote:
> >>>> On 2022-05-20 09:14, dxforth wrote:
> >>
> >>>>> A few may enjoy creating
> >>>>> new parsing words (like the few that enjoy creating macros) but I wouldn't
> >>>>> say either was intrinsic to Forth, or even popular. If creating new parsing
> >>>>> words were popular, wouldn't there already be a convention for it?
> >>>>>
> >>>>> https://pastebin.com/qpZLFc6h
> >>>>
> >>>> The old convention was: don't use any special naming convention for
> >>>> porcelain parsing word, they should look just like ordinary words.
> >>>>
> >>>> For example: "[COMPILE]" and ASCII in Forth-79, POSTPONE in Forth-94
> >>>
> >>> One of the first things that struck me when I learned about the forth language
> >>> was the complete freedom to name words whatever you wanted.
> >>> I do not want to change that!
> >>> What you have presented might be very logical but it looks ugly and does not
> >>> read well.
> >> OK. Could you please order by ugliness (from higher to lower) the
> >> following definitions for the word "ip-in-subnet ( x.ip x.ip-mask
> >> x.ip-net -- flag )":
> >
> > This is how I would write it
> >> : ip-in-subnet >r and r> = ;
> This example is taken for simplicity. Instead, just take your real life
> case when you pass an xt as an argument, or pass a word (or several) as
> an immediate argument.
> > This I can understand after looking up what dip does
> >> : ip-in-subnet ['] and dip = ;
> >
> > The rest are just ugly and difficult to read. ' ´ ` all look the same for me at a quick view
> >> : ip-in-subnet 'and dip = ; \ Tick is for quoting a word
> >> : ip-in-subnet `and dip = ; \ Backtick is for quoting a word
> >> : ip-in-subnet dip' and = ;
> >> : ip-in-subnet dip:and = ;
> >> : ip-in-subnet dip( and ) = ;
> >> : ip-in-subnet dip{ and } = ;
> >
> > What I do not understand is this drive to pass an XT as argument.
> No any xt is passed in the last four code examples.
> > For sure it can be powerful in certain cases,
> > but you do not need to rewrite everything in that style.
> Actually, it's my position too.
>
> Have a look [1], I started from a combinator (a word that accepts an xt
> on the stack), and then introduced an equivalent parsing word:
>
> | Now let's consider a variant of the "dip" combinator
> | that accepts a word to be executed as an immediate argument
> | and generates a more efficient code. Also, this variant can
> | be better readable when the word is known in advance.
>
> I provided two reasons for that:
>
> 1. Potentially, more efficient code.
> 2. Potentially, better readability.
>
>
> In general, I talk not only about passing xt, but passing any argument
> (for example, a name string).
>
> Accepting immediate arguments can be a good choice in many cases. But a
> common problem that authors don't mark these arguments in the source
> code explicitly. And that worsens readability.
>
>
> So for the words having immediate arguments — I want the boundaries of
> these arguments be easy visible. And in the same time I want to have the
> corresponding ("plumbing") words that accepts argument from the data
> stack (or, reluctantly, a technique like "execute-parsing" at least).

To make them visible I have a completely different solution.
I have written a context sensitive Forth colorizer for the text editor I am using (SciTe)

After I add parsing words to the right section they will color their arguments different
then ordinary text. It is a great help for readability.

Peter
>
> [1] https://github.com/ForthHub/discussion/discussions/112
>
>
> --
> Ruvim

On 2022-05-29, albert wrote:
> In article <t6tldc$2k1$1@dont-email.me>, Ruvim <ruvim.pinka@gmail.com> wrote:

>> And if a porcelain parsing word is allowed to be used in compilation
>> state and in interpretation state, it should accept immediate arguments
>> in both cases (or explicitly show that an argument is passed via the
>> stack instead).
>
> A user of my reverse engineering assembler would use "porcelain"
> words only. These are a layer separated from reality, and can
> be used only via meticulous documentation.
> You are spreading an illusion of git-people, that porcelain words
> are intuitive. That makes git all but unusable for the casual
> user.

I don't imply the idea of intuitiveness at all.

In Git, plumbing commands "to be used as building blocks for new tools
and custom scripts" [1], "these commands are primarily for scripted use"
[2].

Porcelain commands are high-level commands [3]. These commands are
intended for direct use and their output format may be changed (to make
it better readable by humans) by evolving.

Using this terminology, "parse-name" is a plumbing word in Forth. The
word "constant" is a porcelain word (which is intended for direct use).
But we don't have a corresponding plumbing word to create a constant.

[1] Git Internals - Plumbing and Porcelain
https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain

[2] Low-level commands (plumbing)
https://git.github.io/htmldocs/git.html#_low_level_commands_plumbing

[3] High-level commands (porcelain)
https://git.github.io/htmldocs/git.html#_high_level_commands_porcelain

--
Ruvim

On 2022-05-30, P Falth wrote:
> On Sunday, 29 May 2022 at 21:23:44 UTC+2, Ruvim wrote:
[...]
>> So for the words having immediate arguments — I want the boundaries of
>> these arguments be easy visible. And in the same time I want to have the
>> corresponding ("plumbing") words that accepts argument from the data
>> stack (or, reluctantly, a technique like "execute-parsing" at least).
>
> To make them visible I have a completely different solution.
> I have written a context sensitive Forth colorizer for the text editor I am using (SciTe)
>
> After I add parsing words to the right section they will color their arguments different
> then ordinary text. It is a great help for readability.

I see. Probably, this solution is acceptable for individuals or very
small collectives.

But this solution is not scalable on the whole Forth ecosystem. It is
not suitable for shared code and distributed development.

--
Ruvim

In article <t6vvk4$bl7$1@dont-email.me>, Ruvim <ruvim.pinka@gmail.com> wrote:
>On 2022-05-28 17:22, Anton Ertl wrote:
>> Ruvim <ruvim.pinka@gmail.com> writes:
>>> On 2022-05-19 18:47, Anton Ertl wrote:
>>>> Instead of ['] FOO, I write `FOO. The latter can be copy-pasted into
>>>> interpretive code.
>>>
>>> To quoting a word I prefer the form 'FOO (i.e. Tick vs Backtick) for the
>>> following reasons:
>>> - it is closer to "[']" and "'" (so it's already connotated with
>>> quoting a word in Forth);
>>> - it is also used for quoting in some other languages (e.g., in Lisp,
>>> to quote a list).
>>>
>>> Possible disadvantage of this choice are as follows.
>>>
>>> - Sometimes Tick is an actual part of a name. But those who use names
>>> starting with a Tick probably will not use recognizers, but parsing words.
>>
>> Gforth currently has the following words starting with ':
>>
>> '-error ' 'quit 'cold 'image 'clean-maintask
>>
>> and Gforth has recognizers. Also, I have seen several programs that
>> define words with names starting with ' (and often paired with a word
>> with a name without ', such as 'QUIT and QUIT). For ` I have yet to
>> see someone write a word that starts with that. As soon as someone
>> loads that program in a system with a '-recognizer, there are the
>> following potential problems:
>>
>> * The user may be unaware of the existence of 'QUIT, and writes 'QUIT
>> with the intention of getting the xt of QUIT, but gets something
>> else because the word-recognizer precedes the '-recognizer.
>>
>> * If, OTOH, the '-recognizer preceded the word-recognizer, you get the
>> converse problem: If you want to get at the word 'QUIT, you get the
>> xt of QUIT instead.
>
>
>As a user, I would prefer the tick-recognizer precedes the
>word-recognizer. Since I know that I always use a leading tick either to
>quoting a word, or for a character literal (when the lexeme ends with a
>tick and consists of 3 xchars), and don't use a tick in names at all.

In ciforth the question is moot. Recognizers (prefixes) are present
in the dictionary in wordlists. Normal precedence rules apply.
If a recognizer is present in a VOCABULARY, you can switch it off
by not adding that vocabulary to the search order.
The exception position for numbers (and other denotations) was a
major design flaw in the original Forth.
Note that Moore himself moved away from that in colorforth.

>
>--
>Ruvim

Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

On Sunday, May 29, 2022 at 3:29:12 PM UTC-5, P Falth wrote:
> I have written a context sensitive Forth colorizer for the text editor I am using (SciTe)
>

VIM has a color setup for each language including Forth and user can
modify, add to or change color, as needed. My Forth is ever evolving and I
haven't changed the color setting in last 10 years so in effect I have little
reliance on color. But that's just me :)
--
me

On 30/05/2022 16:28, albert wrote:
> In article <t6vvk4$bl7$1@dont-email.me>, Ruvim <ruvim.pinka@gmail.com> wrote:
>>On 2022-05-28 17:22, Anton Ertl wrote:
>>> Ruvim <ruvim.pinka@gmail.com> writes:
>>>> On 2022-05-19 18:47, Anton Ertl wrote:
>>>>> Instead of ['] FOO, I write `FOO. The latter can be copy-pasted into
>>>>> interpretive code.
>>>>
>>>> To quoting a word I prefer the form 'FOO (i.e. Tick vs Backtick) for the
>>>> following reasons:
>>>> - it is closer to "[']" and "'" (so it's already connotated with
>>>> quoting a word in Forth);
>>>> - it is also used for quoting in some other languages (e.g., in Lisp,
>>>> to quote a list).
>>>>
>>>> Possible disadvantage of this choice are as follows.
>>>>
>>>> - Sometimes Tick is an actual part of a name. But those who use names
>>>> starting with a Tick probably will not use recognizers, but parsing words.
>>>
>>> Gforth currently has the following words starting with ':
>>>
>>> '-error ' 'quit 'cold 'image 'clean-maintask
>>>
>>> and Gforth has recognizers. Also, I have seen several programs that
>>> define words with names starting with ' (and often paired with a word
>>> with a name without ', such as 'QUIT and QUIT). For ` I have yet to
>>> see someone write a word that starts with that. As soon as someone
>>> loads that program in a system with a '-recognizer, there are the
>>> following potential problems:
>>>
>>> * The user may be unaware of the existence of 'QUIT, and writes 'QUIT
>>> with the intention of getting the xt of QUIT, but gets something
>>> else because the word-recognizer precedes the '-recognizer.
>>>
>>> * If, OTOH, the '-recognizer preceded the word-recognizer, you get the
>>> converse problem: If you want to get at the word 'QUIT, you get the
>>> xt of QUIT instead.
>>
>>
>>As a user, I would prefer the tick-recognizer precedes the
>>word-recognizer. Since I know that I always use a leading tick either to
>>quoting a word, or for a character literal (when the lexeme ends with a
>>tick and consists of 3 xchars), and don't use a tick in names at all.
>
> In ciforth the question is moot. Recognizers (prefixes) are present
> in the dictionary in wordlists. Normal precedence rules apply.
> If a recognizer is present in a VOCABULARY, you can switch it off
> by not adding that vocabulary to the search order.
> The exception position for numbers (and other denotations) was a
> major design flaw in the original Forth.
> Note that Moore himself moved away from that in colorforth.

There's not much Moore hasn't move away from. Having left Forth Inc
there was nothing to hold him back. Whenever he announced a new forth
there'd be a flurry of interest only for it to dissipate. For all the
rhetoric, it seems few forthers are willing to venture 'beyond the fields
we know' to borrow Dunsany's phrase. We're ready to accept - provided
Standard Forth approves.

Ruvim <ruvim.pinka@gmail.com> writes:
>On 2022-05-30, P Falth wrote:
>> On Sunday, 29 May 2022 at 21:23:44 UTC+2, Ruvim wrote:
>[...]
>>> So for the words having immediate arguments — I want the boundaries of
>>> these arguments be easy visible. And in the same time I want to have the
>>> corresponding ("plumbing") words that accepts argument from the data
>>> stack (or, reluctantly, a technique like "execute-parsing" at least).
>>
>> To make them visible I have a completely different solution.
>> I have written a context sensitive Forth colorizer for the text editor I am using (SciTe)
>>
>> After I add parsing words to the right section they will color their arguments different
>> then ordinary text. It is a great help for readability.
>
>
>I see. Probably, this solution is acceptable for individuals or very
>small collectives.
>
>But this solution is not scalable on the whole Forth ecosystem. It is
>not suitable for shared code and distributed development.

Why not?

Sure, you may need to add the parsing words to multiple editors, but
that's doable. And you don't add that many parsing words.

I guess that with the language server protocol you can add the parsing
words to several editors at once.

Of course, with a naming convention you would just add the convention
to the editor, no need to add every word separately, so a large
project might want to introduce such a convention.

One very general way would be to load the project into a Forth system,
and use the system's parsing and recognizing for coloring: If a piece
of source code is parsed with with something other than the text
interpreter's PARSE-NAME or one of a list of pre-defined parsing words
(e.g., S", (, \), you give the parsing-word-parsed colour to the piece
of source code. You colour stuff parsed by the text interpreter based
on the recognizer that recognizes it, and stuff parsed by S", (, \,
and maybe a few others separately. You have to find some way to
continue parsing after an error to make this approach usable.

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Anton Ertl schrieb am Montag, 30. Mai 2022 um 13:02:59 UTC+2:
> Ruvim <ruvim...@gmail.com> writes:
> >On 2022-05-30, P Falth wrote:
> >> On Sunday, 29 May 2022 at 21:23:44 UTC+2, Ruvim wrote:
> >[...]
> >>> So for the words having immediate arguments — I want the boundaries of
> >>> these arguments be easy visible. And in the same time I want to have the
> >>> corresponding ("plumbing") words that accepts argument from the data
> >>> stack (or, reluctantly, a technique like "execute-parsing" at least).
> >>
> >> To make them visible I have a completely different solution.
> >> I have written a context sensitive Forth colorizer for the text editor I am using (SciTe)
> >>
> >> After I add parsing words to the right section they will color their arguments different
> >> then ordinary text. It is a great help for readability.
> >
> >
> >I see. Probably, this solution is acceptable for individuals or very
> >small collectives.
> >
> >But this solution is not scalable on the whole Forth ecosystem. It is
> >not suitable for shared code and distributed development.
> Why not?
>
> Sure, you may need to add the parsing words to multiple editors, but
> that's doable. And you don't add that many parsing words.
>
> I guess that with the language server protocol you can add the parsing
> words to several editors at once.
>
> Of course, with a naming convention you would just add the convention
> to the editor, no need to add every word separately, so a large
> project might want to introduce such a convention.
>
> One very general way would be to load the project into a Forth system,
> and use the system's parsing and recognizing for coloring: If a piece
> of source code is parsed with with something other than the text
> interpreter's PARSE-NAME or one of a list of pre-defined parsing words
> (e.g., S", (, \), you give the parsing-word-parsed colour to the piece
> of source code. You colour stuff parsed by the text interpreter based
> on the recognizer that recognizes it, and stuff parsed by S", (, \,
> and maybe a few others separately. You have to find some way to
> continue parsing after an error to make this approach usable.
> - anton
> --

Aargh... non-immediate state-dependent parsing words,
camouflaged as recognizers, back-ticked for short-hand notation,
colorized with respect to daltonians, are certainly Forth's future.

On 2022-05-30 14:24, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
>> On 2022-05-30, P Falth wrote:
>>> On Sunday, 29 May 2022 at 21:23:44 UTC+2, Ruvim wrote:
>> [...]
>>>> So for the words having immediate arguments — I want the boundaries of
>>>> these arguments be easy visible. And in the same time I want to have the
>>>> corresponding ("plumbing") words that accepts argument from the data
>>>> stack (or, reluctantly, a technique like "execute-parsing" at least).
>>>
>>> To make them visible I have a completely different solution.
>>> I have written a context sensitive Forth colorizer for the text editor I am using (SciTe)
>>>
>>> After I add parsing words to the right section they will color their arguments different
>>> then ordinary text. It is a great help for readability.
>>
>>
>> I see. Probably, this solution is acceptable for individuals or very
>> small collectives.
>>
>> But this solution is not scalable on the whole Forth ecosystem. It is
>> not suitable for shared code and distributed development.
>
> Why not?
>
> Sure, you may need to add the parsing words to multiple editors, but
> that's doable. And you don't add that many parsing words.

1. Parsing words of one project can conflict with parsing words of other
project.

Do you really think that every "dip_ x" can be globally reserved as a
parsing word? (taking into account that naming convention is not used,
and parsing words are named as other ordinary words).

2. This solution forces to use only editors that can highlight text by
known protocol. But some people don't use highlighting at all.

> I guess that with the language server protocol you can add the parsing
> words to several editors at once.
>
> Of course, with a naming convention you would just add the convention
> to the editor, no need to add every word separately, so a large
> project might want to introduce such a convention.

Yes. And a system of reusable Forth packages (that I keep in mind) is a
large project in this sense.

> One very general way would be to load the project into a Forth system,
> and use the system's parsing and recognizing for coloring: If a piece
> of source code is parsed with with something other than the text
> interpreter's PARSE-NAME or one of a list of pre-defined parsing words
> (e.g., S", (, \), you give the parsing-word-parsed colour to the piece
> of source code. You colour stuff parsed by the text interpreter based
> on the recognizer that recognizes it, and stuff parsed by S", (, \,
> and maybe a few others separately. You have to find some way to
> continue parsing after an error to make this approach usable.

I used this approach for correct programs that are loaded into the Forth
system. I changed the Forth text interpreter in such a way that it
generates XML during translation of source code.

After that I generated XHTML (from XML) with code highlighting
(including parsed parts or immediate arguments, immediate words,
numbers, etc), links to other files (that were subjects of INCLUDED),
cross-references (i.e., places where a word is used), and links to the
definition for each word.

I didn't need to specially handle standard words like S", (, \, etc.

All text that was read from the input stream during translation of a
word was considered as an immediate argument of this word.

Concerning errors. I think, continue loading after an error could be
dangerous, and it makes a little sense due to more and more incorrect
highlighting, since an error in compilation of one word (especially a
defining word) produces errors in compilation dependent words like an
avalanche, recursively.

I can also imagine this approach in a Forth live coding system,
conceptually something like Holon, but with less restriction on the
source code structure, and having robust mapping to the text files of
source code.

--
Ruvim

On 2022-05-29 18:22, Ruvim wrote:
> On 2022-05-28 17:22, Anton Ertl wrote:
[...]

>> I just hope that, like I do for field words, you will use the
>> (hopefully standardized) string syntax "string" (which already has a
>> lot of mindshare), and that we reach a consensus for a syntax for xt
>> literals, and all use that then.

For all: if you use additional recognizers (beyond words and numbers),
then what recognizers do you prefer to be in the sequence that a
standard system should provide by a request? (I mean, not initially, but
after asking only).

>
>   forth-2023 !perception{
>
>     ... \ code that uses a standard set of recognizers
>     ... \ including 'FOO   `name  wordlist1::wordlist2::name etc
>     ... \ that precede the word-recognizer  (!)
>   }
>
> or
>
>   forth-2023 !perception//   \ up to the end of file
>
>
> (the naming is under construction)

--
Ruvim

On 2022-05-29 22:23, Ruvim wrote:
> On 2022-05-29 20:18, dxforth wrote:

>> I don't care for its length but at least [UNDEFINED] is unambiguous.
>> Were shortness paramount I'd have chosen LACK.  But hey, we need to
>> keep Forth respectable and starched shirts sell better.
>
>
>   lack( foo ) [if]
>      ...
>   [then]
>
> Nice!

Probably, readability of following

"foo" lack [if] ... [then]

is not worser.

--
Ruvim

On 29 May 2022 at 23:10:58 CEST, "Ruvim" <ruvim.pinka@gmail.com> wrote:

> On 2022-05-30, P Falth wrote:
>> On Sunday, 29 May 2022 at 21:23:44 UTC+2, Ruvim wrote:
> [...]
>>> So for the words having immediate arguments — I want the boundaries of
>>> these arguments be easy visible. And in the same time I want to have the
>>> corresponding ("plumbing") words that accepts argument from the data
>>> stack (or, reluctantly, a technique like "execute-parsing" at least).
>>
>> To make them visible I have a completely different solution.
>> I have written a context sensitive Forth colorizer for the text editor I am
>> using (SciTe)
>>
>> After I add parsing words to the right section they will color their
>> arguments different
>> then ordinary text. It is a great help for readability.
>
> I see. Probably, this solution is acceptable for individuals or very
> small collectives.

Why not large collectives?

> But this solution is not scalable on the whole Forth ecosystem. It is
> not suitable for shared code and distributed development.

Why not? Syntax colouring editors have been around for a long time.

Stephen

--
Stephen Pelc, stephen@vfxforth.com
MicroProcessor Engineering, Ltd. - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, +44 (0)78 0390 3612, +34 649 662 974
http://www.mpeforth.com - free VFX Forth downloads

On Monday, May 30, 2022 at 11:14:16 AM UTC-5, Stephen Pelc wrote:

> Why not? Syntax colouring editors have been around for a long time.
>

Unsure if editor syntax coloring is robust enough. Forth has little syntax so
each word will need to be listed. May be sufficient for the standard words but
when additional word-sets are loaded, the editor's syntax coloring will need
to be updated. Is this a problem? Color Forth wouldn't have this problem as
each word has embedded color information (I assume). But then will need some
means of having the Forth interact with the editor display. If Forth words
have a consistent syntax, then editor syntax coloring would have little
problem.
One solution is to have syntax, even if no one likes it, and the editor
displays the word without the syntax but in color based on the syntax
the editor sees. I do that now with comment tags where the pager (less)
converts the tags to color escape codes. The comment text is shown in
color without the tag.
--
me

I have a word LSWT to list Forth words by type, for example the following
lists constants:

consts lswt
CURRENT and CONTEXT are FORTH
SEETABLE SEETABLECount BIT6 MASK5BITS DEADBEEF SEEK_END SEEK_CUR
SEEK_SET RWRR RW WO RO zlitbl zhitbl \T '/' ',' '_' ')' '(' EOT ETX STX
SOH FAM:RW ascR ERRIOR ERRFIG MPAD:END MPAD:MASK MPAD:LIMIT CST.BTREK
CST.START CS0 CSI FIN \N RAWIO SYSARGS SYSCMDL SYSOPTION SHELL PARMS4
DO2AVAL DOAVAL DODOE DOUSR DO2VAR DO2VAL DO2CON DOVAR DOVAL DOCON DOCOL
CST_IF SMAX CHAR STDERR STDOUT STDIN EPIPE EINTR O_NONBLOCK O_APPEND
O_TRUNC O_EXCL O_CREAT O_RDWR O_WRONLY O_RDONLY SYS_FORK SYS_EXECVE
SYS_WAITPID SYS_BRK SYS_CREAT SYS_WRITE SYS_READ SYS_CLOSE SYS_OPEN
SYS_EXIT REC/BLK BFMAGIC IORMAP #BUFF DOVDO DOVEC 0x80 B/SCR B/BUF
TAREAZ TAREA MPADZ MPADB SIBZ SIBB IPCOBZ IPCOB IPCIBZ IPCIB FBUFZ FBUF
MACBZ MACB EM LIMIT FIRST WNMAX C/L BL FALSE TRUE CELL-1 -CELL CELL
FOUR THREE TWO MONE ONE ZERO ok

The word type is determined by its codeword and for defining word
offspring an additional address. As a Forth word's type can be
determined by codeword and an address, any Forth has information
that it can use for coloring.
--
me

On 2022-05-30 20:58, S Jack wrote:
> On Monday, May 30, 2022 at 11:14:16 AM UTC-5, Stephen Pelc wrote:
>
>> Why not? Syntax colouring editors have been around for a long time.
>>
>
> Unsure if editor syntax coloring is robust enough. Forth has little syntax so
> each word will need to be listed. May be sufficient for the standard words but
> when additional word-sets are loaded, the editor's syntax coloring will need
> to be updated. Is this a problem?

> Color Forth wouldn't have this problem as
> each word has embedded color information (I assume). But then will need some
> means of having the Forth interact with the editor display.

In colorForth a color *is* a syntax. It's not a syntax highlighting by
an editor, it's a syntax itself.

A definition

: foo ( flag -- ) if 123 . then ;

is written as

red:foo

white:(
white:flag
white:--
white:)

green:if
green:123
green:.
green:then

green:;

NB: "Green words like if are compiled, but because they are in the macro
wordlist and act like immediate words, they are executed at compile time
like words written explicitly in yellow." [1]

> If Forth words
> have a consistent syntax, then editor syntax coloring would have little
> problem.
> One solution is to have syntax, even if no one likes it, and the editor
> displays the word without the syntax but in color based on the syntax
> the editor sees. I do that now with comment tags where the pager (less)
> converts the tags to color escape codes. The comment text is shown in
> color without the tag.
> --
> me

[1] The colorForth Editor
http://www.greenarraychips.com/home/documents/greg/cf-editor.htm

[2] colorForth
https://colorforth.github.io/cf.htm

[3] Pre-parsed words
https://colorforth.github.io/parsed.html

--
Ruvim

In article <t72l7e$ds5$1@dont-email.me>, Ruvim <ruvim.pinka@gmail.com> wrote:
>On 2022-05-29 22:23, Ruvim wrote:
>> On 2022-05-29 20:18, dxforth wrote:
>
>>> I don't care for its length but at least [UNDEFINED] is unambiguous.
>>> Were shortness paramount I'd have chosen LACK.  But hey, we need to
>>> keep Forth respectable and starched shirts sell better.
>>
>>
>>   lack( foo ) [if]
>>      ...
>>   [then]
>>
>> Nice!
>
>
>Probably, readability of following
>
> "foo" lack [if] ... [then]
>
>is not worser.

In ciforth the basic dictionary search is FOUND
"foo" FOUND
leaves an address or NULL if not found.
So [DEFINED] is not needed, but neither are [IF] [THEN]

"2DROP" FOUND 0=
" : 2DROP DROP DROP ; " ROT AND EVALUATE

Hallmark of a sound design ?

>--
>Ruvim

Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

On Sunday, May 29, 2022 at 8:30:33 PM UTC+2, Ruvim wrote:
> But having shorter string literals it looks better:
> "x" var
> or
> `x var
> 10 `x const

That is a very personal metric. I see strings - not declarations. And I think prefixed
words are b--t ugly.

> Anyway, what can you suggest if I need to create a definition (e.g. a
> constant) programmatically, and its name is passed as an argument?
> Having "const" from the above it could look as:
>
> : foo ( sd.name -- ) ... 10 -rot const ... ;

Try "CREATE". It has been there for a long time.

Hans Bezemer

On 30 May 2022 at 18:58:26 CEST, "S Jack" <sdwjack69@gmail.com> wrote:

> On Monday, May 30, 2022 at 11:14:16 AM UTC-5, Stephen Pelc wrote:
>
>> Why not? Syntax colouring editors have been around for a long time.
>>
>
> Unsure if editor syntax coloring is robust enough.

Well, find out, otherwise this proposal is in the class "I want someone else
to do all the work".

Stephen

--
Stephen Pelc, stephen@vfxforth.com
MicroProcessor Engineering, Ltd. - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, +44 (0)78 0390 3612, +34 649 662 974
http://www.mpeforth.com - free VFX Forth downloads

On 30 May 2022 at 21:01:10 CEST, "S Jack" <sdwjack69@gmail.com> wrote:
>
> The word type is determined by its codeword and for defining word
> offspring an additional address. As a Forth word's type can be
> determined by codeword and an address, any Forth has information
> that it can use for coloring.

Does that apply to Native Code Compilers?

Stephen
--
Stephen Pelc, stephen@vfxforth.com
MicroProcessor Engineering, Ltd. - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, +44 (0)78 0390 3612, +34 649 662 974
http://www.mpeforth.com - free VFX Forth downloads