On Monday, May 30, 2022 at 9:08:27 PM UTC+2, Ruvim wrote:

> 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]
Yeah - and at least two accessibility modes for the colorblind. I think that
making "color" part of the syntax is one of the least well-considered ideas that
Moore has ever had.

The more since syntax coloring has been around for a long time and
particularly successful, I must say. I've created several such schemes myself.

However - I doubt very much that such exotic format would EVER be supported
by any major editor. Not to mention how to encode it in a plain-text format.

You know, something you can copy, paste, compile and it simply works.
Like the stuff I took from a ZX Spectrum to DOS, Windows and finally Linux.

Great invention - I recommend you try it once.

Hans Bezemer

On Monday, May 30, 2022 at 2:08:27 PM UTC-5, Ruvim wrote:
>
> 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:;
>

Ah, that was another suggestion I was going to make; just tag all the words.
But I was thinking a character symbol for the tag:
a:foo
b:(
b:flag
b:--
b:)
c:if
c:123
c:.
c:then
c:;

Lesson learned way back: 40 and 37 were not white on black but normal text
which default color was white on black. Therefore, text attributes did not
have to be changed when the color scheme changed.
--
me

On 31/05/2022 07:24, Hans Bezemer wrote:
> On Monday, May 30, 2022 at 9:08:27 PM UTC+2, Ruvim wrote:
>
>> 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]
> Yeah - and at least two accessibility modes for the colorblind. I think that
> making "color" part of the syntax is one of the least well-considered ideas that
> Moore has ever had.

From my early school days:

https://www.teaching.com.au/product/EY302

those nuns knew how to punish

In article <8e9b4e64-6320-4962-9b2c-ec44ac9affebn@googlegroups.com>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:
>On Monday, May 30, 2022 at 9:08:27 PM UTC+2, Ruvim wrote:
>
>> 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]
>Yeah - and at least two accessibility modes for the colorblind. I think that
>making "color" part of the syntax is one of the least well-considered ideas that
>Moore has ever had.
>
>The more since syntax coloring has been around for a long time and
>particularly successful, I must say. I've created several such schemes myself.
>
>However - I doubt very much that such exotic format would EVER be supported
>by any major editor. Not to mention how to encode it in a plain-text format.
>
>You know, something you can copy, paste, compile and it simply works.
>Like the stuff I took from a ZX Spectrum to DOS, Windows and finally Linux.
>
>Great invention - I recommend you try it once.

You can add a syntax coloring for vim. With Leon Konings we had
a conversion between coloring in a prefix. It was a snap to add
these colouring to vim. The screens in vim looked almost exact
as native colorforth screens, except for the prefix.
A word drop (red) now looks :drop (red).

>
>Hans Bezemer

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 2022-05-30 23:14, Hans Bezemer wrote:
> 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.
>

When you write:

10 constant foo

"constant " is a prefix for "foo".

When you write:

[char] A

"[char] " is a prefix for "A"

Such prefixes are ugly, since you don't have a general rule that tells
you whether some lexeme is a prefix or not.

Just for example, a convention about parentheses could be a rule that
shows such prefixes explicitly.

In Forth, when a word is used, you don't see (from the surrounding
context) how many arguments from the data stack it consumes. But if you
also don't see how many immediate arguments it consumes — it's far worse
for readability.

Concerning string literals, it just less or more concise forms:

string" x"
s" x"
"x"
`x

In every of these variants the boundaries are obvious and good readable
due to special characters and well known conventions.

>> 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.

How does it help to pass a name string via the data stack?

--
Ruvim

On 31/05/2022 18:36, Ruvim wrote:
> On 2022-05-30 23:14, Hans Bezemer wrote:
>> 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.
>>
>
>
> When you write:
>
> 10 constant foo
>
> "constant " is a prefix for "foo".
>
>
> When you write:
>
> [char] A
>
> "[char] " is a prefix for "A"
>
>
> Such prefixes are ugly, since you don't have a general rule that tells
> you whether some lexeme is a prefix or not.
>
> Just for example, a convention about parentheses could be a rule that
> shows such prefixes explicitly.
>
>
> In Forth, when a word is used, you don't see (from the surrounding
> context) how many arguments from the data stack it consumes. But if you
> also don't see how many immediate arguments it consumes — it's far worse
> for readability.
>
>
>
> Concerning string literals, it just less or more concise forms:
>
> string" x"
> s" x"
> "x"
> `x
>
> In every of these variants the boundaries are obvious and good readable
> due to special characters and well known conventions.

Thanks to 200x, folks today think $#%' et al is forth convention when it's
actually imported convention.

On 2022-05-31 13:27, dxforth wrote:
> On 31/05/2022 18:36, Ruvim wrote:
>> On 2022-05-30 23:14, Hans Bezemer wrote:
>>> 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.
>>>
>>
>>
>> When you write:
>>
>> 10 constant foo
>>
>> "constant " is a prefix for "foo".
>>
>>
>> When you write:
>>
>> [char] A
>>
>> "[char] " is a prefix for "A"
>>
>>
>> Such prefixes are ugly, since you don't have a general rule that tells
>> you whether some lexeme is a prefix or not.
>>
>> Just for example, a convention about parentheses could be a rule that
>> shows such prefixes explicitly.
>>
>>
>> In Forth, when a word is used, you don't see (from the surrounding
>> context) how many arguments from the data stack it consumes. But if you
>> also don't see how many immediate arguments it consumes — it's far worse
>> for readability.
(1)

>>
>>
>> Concerning string literals, it just less or more concise forms:
>>
>> string" x"
>> s" x"
>> "x"
>> `x
>>
>> In every of these variants the boundaries are obvious and good readable
>> due to special characters and well known conventions.
>
> Thanks to 200x, folks today think $#%' et al is forth convention when it's
> actually imported convention.

It doesn't matter whether they are imported or not.
Anyway, what would you suggest instead that to solve the problem (1)?

--
Ruvim

On 31/05/2022 20:24, Ruvim wrote:
> On 2022-05-31 13:27, dxforth wrote:
>> On 31/05/2022 18:36, Ruvim wrote:
>>> ...
>>> In Forth, when a word is used, you don't see (from the surrounding
>>> context) how many arguments from the data stack it consumes. But if you
>>> also don't see how many immediate arguments it consumes — it's far worse
>>> for readability.
> (1)
>
>
>>> Concerning string literals, it just less or more concise forms:
>>>
>>> string" x"
>>> s" x"
>>> "x"
>>> `x
>>>
>>> In every of these variants the boundaries are obvious and good readable
>>> due to special characters and well known conventions.
>>
>> Thanks to 200x, folks today think $#%' et al is forth convention when it's
>> actually imported convention.
>
>
> It doesn't matter whether they are imported or not.

It matters when foreign notions of readability are imported with them.

> Anyway, what would you suggest instead that to solve the problem (1)?

For whom is it a problem - not for you since you understand forth better
than most; nor for countless who have used forth for the past four decades.
To deny new users learning and enjoying forth it for what it is as we did -
that would be the tragedy.

On Tuesday, May 31, 2022 at 5:24:54 AM UTC-5, Ruvim wrote:
> Anyway, what would you suggest instead that to solve the problem (1)?

10 constant \ un-named constant
$"bar" \ assign name to latest

42 constant $"bar"

--
me

S Jack schrieb am Dienstag, 31. Mai 2022 um 16:11:37 UTC+2:
> On Tuesday, May 31, 2022 at 5:24:54 AM UTC-5, Ruvim wrote:
> > Anyway, what would you suggest instead that to solve the problem (1)?
> 10 constant \ un-named constant
> $"bar" \ assign name to latest
>
> 42 constant $"bar"

Cool!
:NONAME 10 ; \ unnamed def
$"bar" \ assign name to latest
: $"bar" 42 ;
You made my day!

On Tuesday, May 31, 2022 at 12:29:17 PM UTC-5, minf...@arcor.de wrote:

Tweeked it a little:
:) frogd
ELF32X86_64 Frog Version 1.0d

"job" /go
: constant ( n -- ) docon , here swap , ;
: s: ( name xt -- ) defer cfa latest pfa dfa ! ;

42 constant s: bar
bar space . 42

-fin-
ok
--
me

On Tuesday, May 31, 2022 at 1:50:54 PM UTC-5, S Jack wrote:
> On Tuesday, May 31, 2022 at 12:29:17 PM UTC-5, minf...@arcor.de wrote:
>
> Tweeked it a little:
> :) frogd
> ELF32X86_64 Frog Version 1.0d
>
> "job" /go
> : constant ( n -- ) docon , here swap , ;
> : s: ( name xt -- ) defer cfa latest pfa dfa ! ;
>
> 42 constant s: bar
> bar space . 42
>
> -fin-
> ok
> --
> me
Oops, stack effects should be: constant ( n -- xt )
--

On Tuesday, May 31, 2022 at 2:02:18 PM UTC-5, S Jack wrote:
More tweek:

: constant ( n -- xt ) docon , here swap , ;
: :: ( xt -- ) aka ;

42 constant :: bar
i. bar . ==> 42

:noname ." FOOBAR" ; :: foo
i. foo ==> FOOBAR

-fin-
ok

In article <t74k1q$jsu$1@dont-email.me>, Ruvim <ruvim.pinka@gmail.com> wrote:
<SNIP>
>In Forth, when a word is used, you don't see (from the surrounding
>context) how many arguments from the data stack it consumes. But if you
>also don't see how many immediate arguments it consumes — it's far worse
>for readability.

I have a syntax coloring that does exactly that (shows fan in/fan out)
by coloring.
https://home.hccnet.nl/a.w.m.van.der.horst/forthlectureE.html
Never catches on.

> "x"
The only thing you need to remember is that " introduces a string.

I like it.

<SNIP>
>
>--
>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

Stephen Pelc <stephen@vfxforth.com> writes:
>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?

If you design for it, it does.

If you don't design for that, it does not matter whether you have a
native-code compiler or some other kind of compiler. E.g., consider a
Forth system that defines

: constant ( n "name" -- )
>r : r> postpone literal postpone ; ;

and then the user defines

5 constant x
: y 5 ;

The resulting code will be the same, so you have no way to know
whether y or x has been defined with constant or : by looking at the
resulting code.

- 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 Tuesday, May 31, 2022 at 5:59:22 AM UTC+2, dxforth wrote:
> From my early school days:
> https://www.teaching.com.au/product/EY302
> those nuns knew how to punish

You weren't inventive enough - they gave you 72 rods to throw to their heads.
That'll teach them about their didactic values.

Hans Bezemer

On Tuesday, May 31, 2022 at 10:36:13 AM UTC+2, Ruvim wrote:
> When you write:
> 10 constant foo
> "constant " is a prefix for "foo".
> When you write:
> [char] A
> "[char] " is a prefix for "A"
Well, your ontology sucks. And that's why your whole argument following
it falls apart:

"A prefix is a PART of a word attached to a beginning of a word which
modifies the meaning of that stem".

[CHAR] is NOT a prefix, because it ISN'T part of that word (even in the
sense of "word" in a Forth context). 'A' HAS a prefix, though, because
the quote signifies it is a character. [CHAR] however, is a word in itself
that executes. It is far more flexible, because it doesn't require any
changes to the interpreter. In that sense - it's more Forth-like.

Moore never liked "hooks" - and that's EXACTLY what "recognizers" are:
lots of needless hooks, which could be handled more elegantly and
Forth-like - by a word.
> Such prefixes are ugly, since you don't have a general rule that tells
> you whether some lexeme is a prefix or not.
Naming is everything. In my libs, I tend to use the rule that privates
are (WORD), so I only have to look for parenthesis words to HIDE.

[WORD] are used at compile time. So, when introducing a new word I
tend to ask myself "is this done at compile time". >WORD put something
somewhere. WORD> gets something from somewhere.

/WORD signify a quantity on a "per" basis, while #WORD defines an
absolute quantity. If you do that consistently, it will help you to properly
and easily read your program.

Given that Forth was designed as a language that puts the burden
fully unto the programmer, simply take that responsibility, instead of
trying to fix things that in the context of this philosophy aren't broken.

As a matter of fact, in "Thinking Forth", Moore elaborates on the
importance of "naming". I devoted an entire Wiki page on it:
https://sourceforge.net/p/forth-4th/wiki/What%27s%20in%20a%20name%3F/

> > Try "CREATE". It has been there for a long time.
> How does it help to pass a name string via the data stack?
For what? For the odd occasion you do things like "function composition"?
I've got such a lib since 2013. We're writing 2022 now and I still gotta find
an real life application for it that goes beyond a demo program.

And I play around a LOT with execution tokens. Forth is not Lisp. If you
want to write C, write C. If you want to write Lisp, write Lisp. If you can't
write Forth - don't write Forth.

But don't bother me with proposals that are clearly intended to turn this
language into another, because some people can't handle it - and hence
argue "that it's made to make programmers lives easier".

Gee man, I got my own compiler. If I wanted to make my life "easier" I'd
already done it in a way that doesn't make me barf on my own listings.

Hans Bezemer

On 1/06/2022 21:47, Hans Bezemer wrote:
> On Tuesday, May 31, 2022 at 5:59:22 AM UTC+2, dxforth wrote:
>> From my early school days:
>> https://www.teaching.com.au/product/EY302
>> those nuns knew how to punish
>
> You weren't inventive enough - they gave you 72 rods to throw to their heads.
> That'll teach them about their didactic values.

They were undoubtedly cruel. But fair.