What's your preference?

I understand that we don't want to yell, but yelling makes you want to use fewer words.

It seems the relative absence of braces and parenthesis compared to other languages may factor in. Lower case makes them stand out more. Not an advantage in Forth.

Lower case for comments and upper case for code makes the two easy to visually differentiate.

Chuck used lower case for colorForth. Maybe he was tired of yelling.

On Thursday, March 3, 2022 at 12:37:41 PM UTC-6, Brad Eckert wrote:
> What's your preference?

Insensitive (cost no problem). My Hungarian syntax in code use both cases:
svFOO \ string variable FOO
But when in command mode I just type "svfoo"; don't bother with shift key.
--
taz

On Thursday, March 3, 2022 at 1:37:41 PM UTC-5, Brad Eckert wrote:
> What's your preference?
>
> I understand that we don't want to yell, but yelling makes you want to use fewer words.
>
> It seems the relative absence of braces and parenthesis compared to other languages may factor in. Lower case makes them stand out more. Not an advantage in Forth.
>
> Lower case for comments and upper case for code makes the two easy to visually differentiate.
>
> Chuck used lower case for colorForth. Maybe he was tired of yelling.

My problem is that I'm an intermittent coder. The result is I end up with different conventions at different times. I've never found that any one style of capitalization was inherently better than others. I've never coded in all caps however. That gives me flashbacks to editing code on teletype devices and punched cards, something I never want to do again. I remember some of the massive equipment they had to do things like, sort cards and other operations that are a push of a button today.

I'm not sure you are even talking about mixed case. Don't most coders use upper/lower case to indicate something in Forth? No?

Would it make any sense to divide words into nouns and verbs with one capitalized?

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

Brad Eckert <hwfwguy@gmail.com> writes:
> What's your preference?

I tend to use upper case for keywords, to make the control flow stand out:

: foo ( n -- n ) baz 3 > IF thingy ELSE whatsit THEN ;

On Thursday, March 3, 2022 at 7:37:41 PM UTC+1, Brad Eckert wrote:
> What's your preference?
Well, "lower case letters are easier to read" is a myth (https://www.sciencedirect.com/science/article/pii/S0042698907002830) - or (at least) more nuanced than is usually thought. So, given that, I think it comes down to my own impressions. My own (Forth) programs are "lower case" where libraries are concerned and Camel Case with applications.

I tend to follow the wording guidelines of "Thinking Forth" - so: in a library you tend to find several (words) that are hidden later on. Other favorites of mine are #quantity, /size, >tosomething, fromsomething>, ?conditionalexecution and leavingaboolean?. Ticks - not that much, because I find it plain ugly.

My preference for lower case can be found in C (which I used intensively before Forth). My preference for Camel Case in applications as well.

I do not prefer a particular style when accepting submissions - for the simple reason that those people have as much right to using a particular style as I have. When maintaining those sources, I tend to mimic these styles. Nothing is a horrible as "Frankenstein sources". Of course, certain (technical) guidelines have to be fulfilled, but that's got little to do with style (e.g. HIDE your internal words - when libs are concerned).

I tend to like "single line words". If conditional or iterative constructs can be closed on a single line, do so. If they can't - use the "long format".

I know I'm overdoing things, but I don't think you can discuss "style" without taking these into consideration.

Hans Bezemer

Paul Rubin <no.email@nospam.invalid> writes:
> I tend to use upper case for keywords, to make the control flow stand out:
> : foo ( n -- n ) baz 3 > IF thingy ELSE whatsit THEN ;

Which, to most modern eyes, is indistinguishable from an old man sitting
on his porch yelling "YOU KIDS GET OFF MY LAWN".

(ALL CAPS == "shouting")

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html

On Friday, March 4, 2022 at 10:31:17 AM UTC-5, Andy Valencia wrote:
> Paul Rubin <no.e...@nospam.invalid> writes:
> > I tend to use upper case for keywords, to make the control flow stand out:
> > : foo ( n -- n ) baz 3 > IF thingy ELSE whatsit THEN ;
> Which, to most modern eyes, is indistinguishable from an old man sitting
> on his porch yelling "YOU KIDS GET OFF MY LAWN".
>
> (ALL CAPS == "shouting")

I think that is the point, shout the flow control to allow it to be recognized easily and mentally disposed of. The details are spoken more quietly because they take a bit of thought.

--

Rick C.

-+ Get 1,000 miles of free Supercharging
-+ Tesla referral code - https://ts.la/richard11209

On 3/3/22 1:37 PM, Brad Eckert wrote:
> What's your preference?

I generally use lower case. I like syntax coloring editors for hiliting
things like comments, control flow words, string literals, etc. Upper
case requires the shift key and I'm a lazy typer.

I may use some camelCase but have no rules for it.

In addition to making source easier to read (for me), a syntax coloring
editor will catch some common typo errors instead of waiting for the
Forth compiler to flag the error. For example if I forget the space
after a '(' or '\' comment then the text won't turn green as I type. If
I for get to delimit some 'S" xxx' text with a '"' then subsequent
source will stay brown. I use color sparingly. Like candy, a little is
good, too much makes me sick.

The disadvantage is not many editors provide user-customizable syntax
coloring. My favorite editor is the Vfx MacForth editor written by Ward
McFarland. As that only works on older 32-bit Macs, I have found Jedit
to be pretty good as a syntax coloring Forth editor and it is
multi-platform.

-Doug

On Saturday, March 5, 2022 at 11:08:33 AM UTC+1, Doug Hoffman wrote:
[..]
> In addition to making source easier to read (for me), a syntax coloring
> editor will catch some common typo errors instead of waiting for the
> Forth compiler to flag the error. For example if I forget the space
> after a '(' or '\' comment then the text won't turn green as I type. If
> I for get to delimit some 'S" xxx' text with a '"' then subsequent
> source will stay brown. I use color sparingly. Like candy, a little is
> good, too much makes me sick.

That matches my experience. My favorite editor attempts to flag
strings and comments. It gets them wrong in many cases (this
is Forth), but I have never felt that I should turn the feature off.
The time saved for a forgotten quote or space is a sufficient
reward.

Illogical coloring should esthetically displease, but apparently
the text not being all the same color is in some way rewarding
the basic instincts (like a low-res color picture superficially
looks better than a hires b&w one.) Mixing upper and lower
case modulates the average black/white ratio and maybe
has a similar effect.

-marcel

On 3/6/22 2:33 AM, Marcel Hendrix wrote:
> On Saturday, March 5, 2022 at 11:08:33 AM UTC+1, Doug Hoffman wrote:
> [..]
>> In addition to making source easier to read (for me), a syntax coloring
>> editor will catch some common typo errors instead of waiting for the
>> Forth compiler to flag the error. For example if I forget the space
>> after a '(' or '\' comment then the text won't turn green as I type. If
>> I for get to delimit some 'S" xxx' text with a '"' then subsequent
>> source will stay brown.

> That matches my experience. My favorite editor attempts to flag
> strings and comments. It gets them wrong in many cases (this
> is Forth), but I have never felt that I should turn the feature off.
> The time saved for a forgotten quote or space is a sufficient
> reward.

Yes. Flagging typos with the editor through the use of color is
practical and time saving. When I first started using color I did not
even think about this advantage. For example, if 'forget' were a control
flow keyword then my typo in the first paragraph above would have been
flagged. :-)

-Doug

On 4/03/2022 20:49, Paul Rubin wrote:
> Brad Eckert <hwfwguy@gmail.com> writes:
>> What's your preference?
>
> I tend to use upper case for keywords, to make the control flow stand out:
>
> : foo ( n -- n ) baz 3 > IF thingy ELSE whatsit THEN ;

What is a 'keyword' in Forth? Is the following one?

: END POSTPONE EXIT POSTPONE THEN ; IMMEDIATE

Whatever convention one chooses it should be applied consistently. With
FORTH Inc there's never a doubt what that convention is (including to the
developers). Looking through the VFX manual however, it's hard to know
whether there is a convention, and if so, what it might be e.g.

: min \ n1 n2 -- n1|n2 6.1.1880
Given two data stack items preserve only the smallest.

: MAX \ n1 n2 -- n1|n2 6.1.1870
Given two data stack items preserve only the largest.

: umin \ n1 n2 -- n1|n2
Given two data stack items preserve only the smallest.

: umax \ n1 n2 -- n1|n2
Given two data stack items preserve only the largest.

The word index, OTOH, lists everything in lowercase.

On Saturday, March 5, 2022 at 5:08:33 AM UTC-5, Doug Hoffman wrote:
> On 3/3/22 1:37 PM, Brad Eckert wrote:
> > What's your preference?
> I generally use lower case. I like syntax coloring editors for hiliting
> things like comments, control flow words, string literals, etc. Upper
> case requires the shift key and I'm a lazy typer.
>
> I may use some camelCase but have no rules for it.
>
> In addition to making source easier to read (for me), a syntax coloring
> editor will catch some common typo errors instead of waiting for the
> Forth compiler to flag the error. For example if I forget the space
> after a '(' or '\' comment then the text won't turn green as I type. If
> I for get to delimit some 'S" xxx' text with a '"' then subsequent
> source will stay brown. I use color sparingly. Like candy, a little is
> good, too much makes me sick.
>
> The disadvantage is not many editors provide user-customizable syntax
> coloring. My favorite editor is the Vfx MacForth editor written by Ward
> McFarland. As that only works on older 32-bit Macs, I have found Jedit
> to be pretty good as a syntax coloring Forth editor and it is
> multi-platform.

Codewright lets you set up your own syntax coloring. Unfortunately it is only available by back door channels. It's hard to even find it mentioned. Seems someone bought the rights, will sell you a license for $400 or so, but doesn't actually give you any code or materials, just a license!

Codewright was a really good editor. If it had been maintained over the years it would have been a great tool today. I still use it, but it has some issues with the file open dialog and other, similar bits. So it gets used, but it isn't a great tool for code work these days. :-(

--

Rick C.

+- Get 1,000 miles of free Supercharging
+- Tesla referral code - https://ts.la/richard11209

On 3/6/22 9:59 PM, Rick C wrote:
[...]
> Codewright lets you set up your own syntax coloring. Unfortunately it is only available by back door channels. It's hard to even find it mentioned. Seems someone bought the rights, will sell you a license for $400 or so, but doesn't actually give you any code or materials, just a license!
>
> Codewright was a really good editor. If it had been maintained over the years it would have been a great tool today. I still use it, but it has some issues with the file open dialog and other, similar bits. So it gets used, but it isn't a great tool for code work these days. :-(

Yes. It's a pain to get very used to one source code editor and then
have its support dropped. I have been using the MacForth integrated
editor for years. It is written entirely in Forth so one can customize
it pretty easily. Unfortunately it does not run on the most recent Mac
OS. I notice that Anton has been providing, at EuroForth, some
information about IDEs if a Forth has the hooks. I need to take a closer
look at that.

-Doug

On 7 Mar 2022 at 03:14:49 CET, "dxforth" <dxforth@gmail.com> wrote:

> What is a 'keyword' in Forth? Is the following one?

Define keyword.
>
> : END POSTPONE EXIT POSTPONE THEN ; IMMEDIATE

Since (in theory) you cannot distinguish user-defined words from supplied
words,
all words are either keywords or not keywords. Hence, the discussion is
ridiculous.

> Whatever convention one chooses it should be applied consistently. With
> FORTH Inc there's never a doubt what that convention is (including to the
> developers). Looking through the VFX manual however, it's hard to know
> whether there is a convention, and if so, what it might be e.g.

VFX has been around since 1998, and it's predecessor since about 1990.
If our coding practices have not changed in 30+ years you are in far more
trouble than moaning about case consistency.

Actually, we could solve some of these problems by not having a proper manual.
Then we would be like most other Forths.

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 7/03/2022 23:50, Stephen Pelc wrote:
> On 7 Mar 2022 at 03:14:49 CET, "dxforth" <dxforth@gmail.com> wrote:
>
>> What is a 'keyword' in Forth? Is the following one?
>
> Define keyword.
>>
>> : END POSTPONE EXIT POSTPONE THEN ; IMMEDIATE
>
> Since (in theory) you cannot distinguish user-defined words from supplied
> words,
> all words are either keywords or not keywords. Hence, the discussion is
> ridiculous.
>
>> Whatever convention one chooses it should be applied consistently. With
>> FORTH Inc there's never a doubt what that convention is (including to the
>> developers). Looking through the VFX manual however, it's hard to know
>> whether there is a convention, and if so, what it might be e.g.
>
> VFX has been around since 1998, and it's predecessor since about 1990.
> If our coding practices have not changed in 30+ years you are in far more
> trouble than moaning about case consistency.
>
> Actually, we could solve some of these problems by not having a proper manual.
> Then we would be like most other Forths.
>
> Stephen

The less confusion over min/max and umin/umax the better :)

On 3/7/2022, Stephen Pelc wrote:

> and it's predecessor

Correction:

and its predecessor

--
The policy of setting up concentration camps ... was invented by the
British in the war they fought against the Boers for the profit of
Jewish predators in South Africa.
(archive.org/details/nolies)

On Tuesday, March 8, 2022 at 12:08:41 AM UTC+1, Robert L. wrote:
> > and it's predecessor
>
> Correction:
>
> and its predecessor
... and a grammar nazi as well..

That's a VERY LOW score on "Grahams Triangle of Disagreement", my friend.

Hans Bezemer