On Wednesday, December 2, 2020 at 7:55:31 PM UTC-8, dxforth wrote:
> DX-Forth is a Forth language compiler and development system
> for MS-DOS and CP/M-80 operating systems. It is intended to
> be a complete, easy to use, programming tool for the creation
> of turnkey applications.

Hi there,

I was using this recently for the first time (the DOS version), and I'm a Forth newbie, but I did see something unexpected:

`s" foo" s" bar" s+ type`

output was `barbar`, where I expected `foobar`.

Doing a `s" foo" s" bar" .s`, I noticed that both strings have the same address, which explains the first behavior, and contributes to the crash I see when I do this:

: TSE S" E" SWAP EXEC ;

and run it as TSE S" myfile.f" - I was trying to use an external editor :)

Thanks!

On 27/10/2021 06:55, Robert Roland wrote:
>
> I was using this recently for the first time (the DOS version), and I'm a Forth newbie, but I did see something unexpected:
>
> `s" foo" s" bar" s+ type`
>
> output was `barbar`, where I expected `foobar`.
>
> Doing a `s" foo" s" bar" .s`, I noticed that both strings have the same address, which explains the first behavior, and contributes to the crash I see when I do this:
>
> : TSE S" E" SWAP EXEC ;
>
> and run it as TSE S" myfile.f" - I was trying to use an external editor :)
>
> Thanks!
>

DX-Forth supports one interpretive S" string (all that Forth-94 requires).

Instead of providing two as 200x requires, I opted to provide >PAD which
I find to be generally more useful.

Thus your example could be written:

s" foo" >pad s" bar" s+ type

On Tuesday, October 26, 2021 at 12:55:51 PM UTC-7, rob.r...@gmail.com wrote:
> `s" foo" s" bar" s+ type`
>
> output was `barbar`, where I expected `foobar`.
>
> Doing a `s" foo" s" bar" .s`, I noticed that both strings have the same address, which explains the first behavior, and contributes to the crash I see when I do this:
>
> : TSE S" E" SWAP EXEC ;
>
> and run it as TSE S" myfile.f" - I was trying to use an external editor :)

I have had a circular buffer of strings in the novice package since 2010.
The number of strings is currently 16, but this can be set any anything (memory limiting).
The strings are 255 chars.
S" and S| etc. all use the circular buffer.
I don't know what S+ is --- that is not ANS-Forth --- can you define it?

Here is an example of using the circular buffer:
-----------------------------------------------------
\ ******
\ ****** This is our :NAME word.
\ ******

: :name ( str wid -- ) \ like colon except takes its name as a parameter
get-current >r set-current
<cstr
c" : " +cstr +cstr c" " +cstr
cstr> count evaluate
r> set-current ;

: :2name ( prefix-str suffix-str wid -- ) \ used for suffixing or prefixing names
>r concat r> \ -- hstr wid
:name ;

: :3name ( prefix-str mid-str suffix-str wid -- )
>r concat concat r> \ -- hstr wid
:name ;

: :name! ( str wid -- ) \ like :NAME but with a ! suffix
c" !" swap :2name ;

: :name@ ( str wid -- ) \ like :NAME but with a @ suffix
c" @" swap :2name ;

\ It would make a lot more sense if the standard provided us with :NAME
\ and colon was written in terms of it, rather than the other way around.
\ Normal Forth programming involves writing robust words (such as :NAME) first
\ and then building more specific words (such as colon) in terms of them.
\ This is the opposite of what we did here, defining :NAME in terms of colon.
-----------------------------------------------------

Here are of some ANS-Forth words that I rewrote to use the circular buffer:
-----------------------------------------------------
\ ******
\ ****** This is <# # #> etc. rewritten to use <CSTR so there aren't conflicts.
\ ******

: big-um/mod ( ud u -- remainder Dquotient )
>r 2dup \ -- ud ud
dup 0< if -1 else 1 then \ -- ud ud multiplier \ this assures a positive intermediate value in M*/
r@ m*/ 2tuck \ -- Dquotient ud Dquotient
r> 1 m*/ \ -- Dquotient ud Dquotient*divisor
d- \ -- Dquotient Dremainder
abort" *** BIG-UM/MOD remainder overflowed ***"
-rot ;

here ," 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ"
1+ constant digits

: <# ( -- )
<cstr ;

: hold ( char -- )
char+cstr ;

: sign ( n -- )
0< if [char] - hold then ;

: # ( ud1 -- ud2 )
base @ big-um/mod \ -- remainder Dquotient
rot digits + c@ hold ;

: #s ( ud1 -- 0. )
begin # 2dup or 0= until ;

: #> ( ud -- adr cnt )
2drop \ --
cstr> count \ -- adr cnt
2dup reverse-str ;

: word ( delim -- cstr ) \ stream: data...delim
<cstr word +cstr cstr> ;

\ WORD is similar to <# #> in that it uses a static buffer and there is a lot of opportunity for the data to get corrupted.
\ Note that PARSE <+CSTR> can't be used inside of WORD above
\ This is because BL PARSE will return an empty string if there are more than one blank in front of the string. Weird but true!
-----------------------------------------------------

I also have my STRING-STACK.4TH package now that is much better than
the circular buffer and is the preferred way to work with strings.

All of this is written in ANS-Forth.

On Wednesday, October 27, 2021 at 12:31:46 AM UTC+2, dxforth wrote:
> DX-Forth supports one interpretive S" string (all that Forth-94 requires)..
>
> Instead of providing two as 200x requires, I opted to provide >PAD which
> I find to be generally more useful.

I've (since long) adopted a similar solution, but it's automatic since it's part of the VM. As a matter of fact, I turned the PAD into a circular buffer. 4tH knows a lot of temporary strings, since string constants reside in a different segment. In order to become (temporarily) available to the VM, they have to be copied into the PAD. The number generation buffer also resides in the PAD, since it grows downward. The size circular buffer equals the size of the PAD minus the size of the number generation buffer. Technically, they could crash, but this is quite unlikely unless you set out to do so. It's sized double the number of bits of a cell.

In general use, it's quite transparent. There are hardly ever any overwrites - unless you scan a large table or have many iterations on a temporary string. See: https://sourceforge.net/p/forth-4th/wiki/Temporary%20strings/

I know that PAD should be "free to the programmer", but I find very little use for that. It will still work in that regard - if you have carnal knowledge and know what you're doing. E.g. many ANS-Forth tests use PAD that way and they work as advertised almost every single time. The way 4tH uses PAD, however, is infinitely more useful to me.

I don't know how your >PAD works, but may be you should try to make it work as a circular buffer. Just a suggestion ;-)

Hans Bezemer

On Wednesday, October 27, 2021 at 11:10:39 AM UTC+2, Hans Bezemer wrote:
> I don't know how your >PAD works, but may be you should try to make it work as a circular buffer. Just a suggestion ;-)

A little inspiration here. CLAIM can also be used to (temporarily) reserve just a bunch of chars in the buffer. It's 4tH, sure, but I think this will work for ANS as well.

[UNDEFINED] /upad [IF]
4096 constant /upad
[THEN]

/upad string upad
upad /upad + constant upad|
upad value uhld
( n -- a)
: claim dup uhld + upad| > if upad else uhld then dup rot chars + to uhld ;
: >pad dup 1+ claim over >r dup >r place r> r> ;
( a1 n -- a2 n)

Hans Bezemer

On Wednesday, October 27, 2021 at 11:10:39 AM UTC+2, the.bee...@gmail.com wrote:
> In general use, it's quite transparent. There are hardly ever any overwrites -
> unless you scan a large table or have many iterations on a temporary string.

Sounds familiar. I have at least five times thought the same about
the size of the anonymous matrix cache in iForth.

-marcel

On Tuesday, October 26, 2021 at 3:31:46 PM UTC-7, dxforth wrote:
> Thus your example could be written:
>
> s" foo" >pad s" bar" s+ type

That worked! Thank you.

On Tuesday, October 26, 2021 at 9:30:09 PM UTC-7, Hugh Aguilar wrote:
> I don't know what S+ is --- that is not ANS-Forth --- can you define it?

It's string concatenation. From Gforth:

: s+ { addr1 u1 addr2 u2 -- addr u }
u1 u2 + allocate throw { addr }
addr1 addr u1 move
addr2 addr u1 + u2 move
addr u1 u2 +
;

> I also have my STRING-STACK.4TH package now that is much better than
> the circular buffer and is the preferred way to work with strings.

I will look this up and give it a try - thanks!

On 27/10/2021 20:10, Hans Bezemer wrote:
>
> I don't know how your >PAD works, but may be you should try to make it work as a
> circular buffer. Just a suggestion ;-)

My usage doesn't warrant it at the moment. I'll hold out until I'm backed
into a corner :)

On 28/10/2021 03:29, Robert Roland wrote:
> On Tuesday, October 26, 2021 at 9:30:09 PM UTC-7, Hugh Aguilar wrote:
>> I don't know what S+ is --- that is not ANS-Forth --- can you define it?
>
> It's string concatenation. From Gforth:
>
> : s+ { addr1 u1 addr2 u2 -- addr u }
> u1 u2 + allocate throw { addr }
> addr1 addr u1 move
> addr2 addr u1 + u2 move
> addr u1 u2 +
> ;

The nearest thing in DX-Forth is +STRING which a low-level string
concatenation function. In DX-Forth there's no ALLOCATE and no
concept of strings being held 'somewhere' beyond that implied by
WORD PARSE S" HOLD etc. The user manages everything. >PAD can
come in handy but it also is nothing special being defined as:

: >PAD ( adr len -- adr2 len ) PAD 0 +STRING ;

IMO the less 'magic' there is in Forth, the better and the sooner
a programmer realizes there is no Siri in the system looking out
for his well-being, the better.

On Wednesday, October 27, 2021 at 9:29:48 AM UTC-7, rob.r...@gmail.com wrote:
> On Tuesday, October 26, 2021 at 9:30:09 PM UTC-7, Hugh Aguilar wrote:
> > I don't know what S+ is --- that is not ANS-Forth --- can you define it?
> It's string concatenation. From Gforth:
>
> : s+ { addr1 u1 addr2 u2 -- addr u }
> u1 u2 + allocate throw { addr }
> addr1 addr u1 move
> addr2 addr u1 + u2 move
> addr u1 u2 +
> ;

That is awful code! Gforth is not a good source of Forth code; I wouldn't use it.
Here you are using the heap, but there is no documentation to indicate this,
so you are likely to get a memory leak because this never gets freed.

Here is some more code from my novice package.
Note +STRING that is likely the same as DXforth's S+ --- and note that my
documentation says that it should not be used.
Note CONCAT that is much better as this uses the circular buffer.
------------------------------------------------
\ ******
\ ****** This is some more string stuff.
\ ******

: +string ( adrA cntA adrB cntB -- adrA cntA+cntB ) \ append strB to strA
locals| cntB adrB cntA adrA |
adrB adrA cntA + cntB move
adrA cntA cntB + ;

\ In general, +STRING should not be used for concatenating strings. Use +CSTR or (in STRING-STACK.4TH) +$ instead.
\ +STRING is only useful if you know your buffer is large enough to hold the appended string.
\ You should never use PAD or any other global variable for passing data between functions.

: leading-white ( adr cnt -- n ) \ returns a count of how many leading white chars are in the string
dup 0= if nip exit then
bounds 0 -rot do \ -- n
I c@ bl <= if 1+ else leave then
loop ;

: -leading ( adr cnt -- new-adr new-cnt ) \ like -TRAILING except removes leading white-space
2dup leading-white /string ;

: <hstr> ( adr cnt -- hstr ) \ hstr is a copy in the heap
dup char+ alloc >r \ -- adr cnt
dup r@ c!
r@ char+ swap move
r> ;

: hstr ( str -- hstr ) \ hstr is a copy in the heap
count <hstr> ;

: concat ( str1 str2 -- str ) \ concatenates the two counted strings
<cstr swap +cstr +cstr cstr> ;

: ,str ( adr cnt -- ) \ copy string to HERE
here >r dup char+ allot \ don't use ALIGNED, as the caller may have already grabbed HERE
dup r@ c!
r> char+ swap move ;

: ," ( -- ) \ stream: string"
[char] " parse ,str ;

\ Gforth 0.6.2. has a weirdity that prevents me from defining ," like this:
\ : ," postpone s" ,str ;

-1 constant A<B
0 constant A=B
1 constant A>B \ these are the results of COMPARE

: ccompare ( str1 str2 -- A<B | A=B | A>B) \ like COMPARE except for counted-strings
>r count r> count compare ;

: indexed-char ( index adr cnt -- char ) \ the string will be used as an array of chars
rover 0< abort" *** INDEXED-CHAR given a negative index ***"
rover <= abort" *** INDEXED-CHAR given an index too large ***"
+ c@ ;

: hexit>char ( [0,15] -- char )
s" 0123456789ABCDEF" indexed-char ;

8 constant <backspace>
9 constant <tab>
13 constant <cr>
27 constant <esc>

: get-str ( init-str -- str ) \ used for user-interface input
<cstr
dup count type +cstr
begin key dup <cr> <> while
dup case
<backspace> of dup emit space emit 1 -cstr endof
<tab> of drop endof
<esc> of drop endof
dup emit char+cstr
endcase
repeat drop
cstr> ;

\ GET-STR is a slight upgrade on ACCEPT because it takes an init-str that is used as a default.
\ This GET-STR is not compatible with the GET-STR in previous NOVICE.4TH releases that didn't have an init-str.

: get-float ( -- ) \ float: -- n
begin c" 0." get-str count >float not while
cr ." You did not enter a valid number. Try again: " repeat ;

: y/n? ( adr cnt -- y/n? true | false ) \ top flag indicates if string is a valid Yea or Nay
-leading \ -- adr cnt
0= if drop false exit then \ -- adr
c@ \ -- char
dup [char] Y = if drop true true exit then
dup [char] y = if drop true true exit then
dup [char] N = if drop false true exit then
dup [char] n = if drop false true exit then
drop false ;

: <get-y/n> ( -- y/n? true | false ) \ valid?
c" Y" get-str count y/n? ;

: get-y/n ( -- flag )
begin <get-y/n> not while
cr ." You did not enter a valid Yea or Nay. Try again: " repeat ;
------------------------------------------------

> > I also have my STRING-STACK.4TH package now that is much better than
> > the circular buffer and is the preferred way to work with strings.
> I will look this up and give it a try - thanks!

This is no longer posted publicly because I don't want Stephen Pelc
to obtain this code and put it in VFX which he sells.
Stephen Pelc says that anybody can write a better string-stack than mine,
but he doesn't have a string-stack. All that he has is the vague claim that
some anonymous African wrote a better string-stack 30 years ago
(most likely that was just a port of Wil Baden's awful code).

You can obtain the novice-package, including STRING-STACK.4TH
Just send me an email at hughaguilar96@gmail.com
I will send you a copy.

On Wednesday, October 27, 2021 at 6:05:53 PM UTC-7, dxforth wrote:
> On 28/10/2021 03:29, Robert Roland wrote:
> > On Tuesday, October 26, 2021 at 9:30:09 PM UTC-7, Hugh Aguilar wrote:
> >> I don't know what S+ is --- that is not ANS-Forth --- can you define it?
> >
> > It's string concatenation. From Gforth:
> >
> > : s+ { addr1 u1 addr2 u2 -- addr u }
> > u1 u2 + allocate throw { addr }
> > addr1 addr u1 move
> > addr2 addr u1 + u2 move
> > addr u1 u2 +
> > ;
> The nearest thing in DX-Forth is +STRING which a low-level string
> concatenation function. In DX-Forth there's no ALLOCATE and no
> concept of strings being held 'somewhere' beyond that implied by
> WORD PARSE S" HOLD etc. The user manages everything. >PAD can
> come in handy but it also is nothing special being defined as:
>
> : >PAD ( adr len -- adr2 len ) PAD 0 +STRING ;
>
> IMO the less 'magic' there is in Forth, the better and the sooner
> a programmer realizes there is no Siri in the system looking out
> for his well-being, the better.

All of DXforth's code is kindergarten level, such as this.
He is also always spouting pseudo-wisdom such as this bit about Siri.
I recommend that you ignore him --- he's an idiot.
C.L.F. is full of people who want to be teachers of Forth, and so they try to buffalo
newbies such as yourself, but they don't really know anything about Forth.

Way back in 1984 (age 18) as I was transitioning from line-number BASIC
to Forth I knew that PAD was a bad idea. I was well aware that the main problem
in line-number BASIC was that we had only global variables so there was
a lack of reentrancy which severely limited BASIC to only short uncomplicated
programs. I was also aware that PAD was a global variable and had this problem.
I read "Starting Forth" --- it was obvious to me that nobody at Forth Inc. understood
the problem with non-reentrant code --- they were not improving on BASIC at all.

On 28/10/2021 16:29, Hugh Aguilar wrote:
> On Wednesday, October 27, 2021 at 6:05:53 PM UTC-7, dxforth wrote:
>> On 28/10/2021 03:29, Robert Roland wrote:
>> > On Tuesday, October 26, 2021 at 9:30:09 PM UTC-7, Hugh Aguilar wrote:
>> >> I don't know what S+ is --- that is not ANS-Forth --- can you define it?
>> >
>> > It's string concatenation. From Gforth:
>> >
>> > : s+ { addr1 u1 addr2 u2 -- addr u }
>> > u1 u2 + allocate throw { addr }
>> > addr1 addr u1 move
>> > addr2 addr u1 + u2 move
>> > addr u1 u2 +
>> > ;
>> The nearest thing in DX-Forth is +STRING which a low-level string
>> concatenation function. In DX-Forth there's no ALLOCATE and no
>> concept of strings being held 'somewhere' beyond that implied by
>> WORD PARSE S" HOLD etc. The user manages everything. >PAD can
>> come in handy but it also is nothing special being defined as:
>>
>> : >PAD ( adr len -- adr2 len ) PAD 0 +STRING ;
>>
>> IMO the less 'magic' there is in Forth, the better and the sooner
>> a programmer realizes there is no Siri in the system looking out
>> for his well-being, the better.
>
> All of DXforth's code is kindergarten level, such as this.
> He is also always spouting pseudo-wisdom such as this bit about Siri.
> I recommend that you ignore him --- he's an idiot.
> C.L.F. is full of people who want to be teachers of Forth, and so they try to buffalo
> newbies such as yourself, but they don't really know anything about Forth.
>
> Way back in 1984 (age 18) as I was transitioning from line-number BASIC
> to Forth I knew that PAD was a bad idea. I was well aware that the main problem
> in line-number BASIC was that we had only global variables so there was
> a lack of reentrancy which severely limited BASIC to only short uncomplicated
> programs. I was also aware that PAD was a global variable and had this problem.
> I read "Starting Forth" --- it was obvious to me that nobody at Forth Inc. understood
> the problem with non-reentrant code --- they were not improving on BASIC at all.

Thank you, Siri.

On Thursday, October 28, 2021 at 3:05:53 AM UTC+2, dxforth wrote:
> In DX-Forth there's no ALLOCATE and no
> concept of strings being held 'somewhere' beyond that implied by
> WORD PARSE S" HOLD etc. The user manages everything. >PAD can
> come in handy but it also is nothing special being defined as:
A tip: get rid of WORD. PARSE is so much easier since it doesn't involve any copying - and the added dangers of buffer overflow. It's still supported in 4tH as a library, but I don't promote it in any way. It pays off to make programs or words work with PARSE. I haven't used it since ancient times.

Hans Bezemer

On Thursday, October 28, 2021 at 7:29:15 AM UTC+2, Hugh Aguilar wrote:
> All of DXforth's code is kindergarten level, such as this.
Explain. Don't hestitate to go into details.

> He is also always spouting pseudo-wisdom such as this bit about Siri.
> I recommend that you ignore him --- he's an idiot.
You just scored the absolute rock bottom of "Grahams Triangle of Disagreement". Kudos!

> C.L.F. is full of people who want to be teachers of Forth, and so they try to buffalo
> newbies such as yourself, but they don't really know anything about Forth..
Weasel speak. Which people? And where is your detailed classification (of course - with solid criteria) to evaluate Forth knowledge? Barely lifted yourself from the absolute rock bottom of "Grahams Triangle of Disagreement". Well, I guess progress is progress..

> Way back in 1984 (age 18) as I was transitioning from line-number BASIC
> to Forth I knew that PAD was a bad idea.
Why? In those days, PAD was just a temp buffer for stuff.

> I was well aware that the main problem
> in line-number BASIC was that we had only global variables so there was
> a lack of reentrancy which severely limited BASIC to only short uncomplicated
> programs.
I've written several reentrant programs in ZX BASIC. It's not hard. Define an array and use it as a stack. GOSUB will happily recurse. uBasic/4tH even has one built in! PUSH keywords and TOS() and POP() functions. Works like a charm. https://rosettacode.org/wiki/Sorting_Algorithms/Circle_Sort#ZX_Spectrum_Basic

> I was also aware that PAD was a global variable and had this problem.
Forth has lots of global variables. Just take a look at the ANS-Forth glossary. I don't really feel LOCALS are very Forth like, but even then: they don't solve the question of dynamic strings or floats. The point is: either you take the hit of cleaning local up automatically (which they do as well even though NO locals have been defined) or you have to do it manually - with the added problem of introducing bugs. Stacks are elegant. And where variables are concerned - stamp 'em out as much as you can. I did a Wiki page on that one: https://sourceforge.net/p/forth-4th/wiki/This%20is%20Forth/

Good advice from "Thinking Forth"..

> I read "Starting Forth" --- it was obvious to me that nobody at Forth Inc.. understood
> the problem with non-reentrant code --- they were not improving on BASIC at all.
Hmm. No GOTO. Using the stack for transferring values to words. Named subroutines. No line numbers. Compiled code. I'd say those are improvements. BTW, around the same time Classic Basics were popular, there was also BBC Basic. Bought the wrong machine, Hugh?

Hans Bezemer

On 28/10/2021 18:58, Hans Bezemer wrote:
> On Thursday, October 28, 2021 at 3:05:53 AM UTC+2, dxforth wrote:
>> In DX-Forth there's no ALLOCATE and no
>> concept of strings being held 'somewhere' beyond that implied by
>> WORD PARSE S" HOLD etc. The user manages everything. >PAD can
>> come in handy but it also is nothing special being defined as:

> A tip: get rid of WORD. PARSE is so much easier since it doesn't involve any copying - and the added dangers of buffer overflow. It's still supported in 4tH as a library, but I don't promote it in any way. It pays off to make programs or words work with PARSE. I haven't used it since ancient times.

Well, PARSE didn't handle leading delimiters which prompted 200x to
introduce PARSE-NAME. Then there came S\" which involves buffering.
Don't use a buffer - use a buffer. The arguments go around in circles.
When the experts and their competing interests cannot be relied upon,
then one must consider one's own interests.

On Friday, October 29, 2021 at 1:11:20 AM UTC+2, dxforth wrote:
> Well, PARSE didn't handle leading delimiters which prompted 200x to
> introduce PARSE-NAME. Then there came S\" which involves buffering.
> Don't use a buffer - use a buffer. The arguments go around in circles.
True. I solved it differently: I defined OMIT, which parses leading delimiters. Then I defined PARSE-WORD as:
: PARSE-WORD DUP OMIT PARSE ;

The TRUE reason for PARSE-NAME is that it has to parse a number of "white space" characters. I don't like "special cases" in words, so in that sense PARSE-NAME is a logical choice. Due to 4tH's architecture I don't have much use for it (parsing is done by the compiler, written in C), so it became a library. I don't find this requirement for the special "white space" behavior of WORD in the current version of the standard - which means that PARSE is a good alternative. https://forth-standard.org/standard/core/WORD

The WS behavior *IS* listed for PARSE-NAME: https://forth-standard.org/standard/core/PARSE-NAME

Personally, I find PARSE-NAME a bad factor. I think I would have called it S-PARSE ( a1 n1 -- a2 n2) where a1 n1 is a string of delimiters, so you could easily derive PARSE-NAME from that. In my implementation of PARSE-NAME, it follows the 4tH compiler:

: PARSE-NAME omit-ws parse-ws ;

So it's a bit more flexible. I did the very same with S\":

First, the preprocessor:
:macro s\" $#$ " ` S" ` |#| >>> " |#| S>ANS ;

Then the library:
[UNDEFINED] s>escape [IF] include lib/escape.4th [THEN]
[UNDEFINED] s>embed [IF] include lib/embed.4th [THEN]
[UNDEFINED] s>ans [IF] : s>ans s>escape s>embed ; [THEN]

And finally the libraries that expand [a] escapes (char $ c, \ \x) and [b] embedded char constants (char $ , 16 ,). It's all handled during runtime and destroys the original string (true), but apart from porting I've never needed it. Fortunately, because I think it's an abomination. It's simply too over complicated to be (core) Forth. Why not simply a word that C, the darn thing in?

> When the experts and their competing interests cannot be relied upon,
> then one must consider one's own interests.
True. Too often the particular needs of a vendor turns a GOOD library into a BAD wordset. But either following or NOT following the current standardization trends remains a delicate balance - wink, wink, nudge, nudge, say no more.

Hans Bezemer

Hans Bezemer <the.beez.speaks@gmail.com> writes:
>The TRUE reason for PARSE-NAME is that it has to parse a number of "white s=
>pace" characters.

That's one of the differences between PARSE-NAME and PARSE. The other
is that PARSE-NAME skips leading delimiters, while PARSE does not.

>I don't find this requirement for the special "white space" behavi=
>or of WORD in the current version of the standard

|11.3.5 Parsing
| |When parsing from a text file using a space delimiter, control
|characters shall be treated the same as the space character.

And if you look at
<https://forth-standard.org/standard/core/PARSE-NAME>, you find a
comment from me pointing to 11.3.5.

- 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 Thursday, October 28, 2021 at 1:16:15 AM UTC-7, the.bee...@gmail.com wrote:
> > Way back in 1984 (age 18) as I was transitioning from line-number BASIC
> > to Forth I knew that PAD was a bad idea.
> Why? In those days, PAD was just a temp buffer for stuff.

You ask: "Why?" You're an idiot too!
Anybody who uses PAD is an idiot.

Most likely PAD was a quick fix to early Forth's lack of a circular buffer for strings and/or it was used
in a small computer with maybe 1KB of RAM that had minimal need for string processing.
The fact that PAD was put in ANS-Forth indicates that Elizabeth Rather didn't understand
that micro-controllers are different from desktop computers.

> > I was well aware that the main problem
> > in line-number BASIC was that we had only global variables so there was
> > a lack of reentrancy which severely limited BASIC to only short uncomplicated
> > programs.
> I've written several reentrant programs in ZX BASIC. It's not hard.
> Define an array and use it as a stack. GOSUB will happily recurse. uBasic/4tH even has one built in!
> PUSH keywords and TOS() and POP() functions. Works like a charm.
> https://rosettacode.org/wiki/Sorting_Algorithms/Circle_Sort#ZX_Spectrum_Basic

I wrote an article for "Computer Language" magazine that describes this technique.
I provided the Towers of Hanoi program as my example. I was very young then.

Line-number BASIC and PolyForth were both artifacts of the 1980s when programmers
used goofy work-arounds like this --- both were embarrassments of the era.

On Thursday, October 28, 2021 at 1:16:15 AM UTC-7, the.bee...@gmail.com wrote:
> On Thursday, October 28, 2021 at 7:29:15 AM UTC+2, Hugh Aguilar wrote:
> > All of DXforth's code is kindergarten level, such as this.
> Explain. Don't hestitate to go into details.
> > He is also always spouting pseudo-wisdom such as this bit about Siri.
> > I recommend that you ignore him --- he's an idiot.
> You just scored the absolute rock bottom of "Grahams Triangle of Disagreement". Kudos!

If I have to explain why PAD is a bad idea, then you won't understand.
If I knew this at age 18 in 1984 with only line-number BASIC as my background,
then you should know this too in 2021. How did I know this? It was obvious!

Your reference to Paul Graham's Triangle indicates that you want me to consider
you to be my peer --- I'm pretty sure that Paul Graham presumed discussions between peers.

This reminds me of a case in which Albert van der Horst said that I had come up with
the idea of using structs for OOP, that Doug Hoffman considers to be an interesting idea:

On Thursday, August 20, 2020 at 7:43:52 PM UTC-7, hughag...@gmail.com wrote:
> On Thursday, August 20, 2020 at 6:40:38 AM UTC-7, none albert wrote:
> > In article <5f3e7308$0$701$1472...@news.sunsite.dk>,
> > Doug Hoffman <glid...@gmail.com> wrote:
> > >On 8/19/20 7:42 AM, albert wrote:
> > >
> > >> Now there is an interesting idea. It helps out with single inheritance.
> > >
> > >Every Forth objects extension I've seen (since 1984, all class based)
> > >has used some form of struct mechanism for instance variable
> > >inheritance. Both with and without duck typing. But I may have missed some.
> >
> > Of course that is not true for extremely simple, one or two screen
> > oo. Most of those you will have missed, because every Forther has
> > written one, they just don't publish them.
> > I think this idea is simple enough to be be added to a one or two
> > screen oo-package. That is why I think it is interesting.
> > (That Aguilar comes up with it is not a reason to dismiss it.)
> You can't have OOP without structs.
>
> I didn't "come up with" this "interesting idea" of using the
> parent class size as the base index for the child class definition.
> This is fundamental to OOP --- this is how inheritance works.
>
> This reminds me of a plumber I worked with: Johnny the Jew
> He was a really weird guy! Among other things, he believed that
> the Earth was flat. I pointed out some of the more obvious evidence
> indicating that the Earth is a globe, including the way that ships
> disappear over the horizon rather than just appear smaller and smaller,
> although they do appear smaller due to being further away.
> He said: "Wow! That makes sense! I need to revise my thinking regarding
> the Earth being flat, and consider the possibility that it is a globe."
> I had to bite the sleeve on my hoodie to prevent myself from laughing.
> Everybody else in the world revised their thinking on that subject
> about four centuries ago --- he is a little bit behind the curve!
>
> OOP isn't four centuries hold, but it is more than four decades old.
> The ANS-Forth cult seems to be a little bit behind the curve!

I was being patient with Johnny the Jew in explaining that Earth is a globe.
I'm not being patient with DXforth and the Beez in explaining why
PAD is a bad idea --- this is because both of them talk down to me as if
I were a stupid little novice and they were bosses.

BTW: Later on, Johnny the Jew was spouting some offensive nonsense about
Catholicism and one of the Mexicans punched him in the face. He called the cops
but nothing came of this because nobody would be a witness on his behalf.
The foreman did kick the Mexican off the job site. That guy had to plead
his case at the labor office, but they apparently were sympathetic because
they just transferred him to a different job site --- he is an experienced plumber
so they didn't want him to go to work for the competition --- I haven't seen
Johnny the Jew since that time though, so I think he got fired (he didn't know
any more about plumbing than he did about religion).

On 29/10/2021 23:55, Hans Bezemer wrote:
> On Friday, October 29, 2021 at 1:11:20 AM UTC+2, dxforth wrote:
>> Well, PARSE didn't handle leading delimiters which prompted 200x to
>> introduce PARSE-NAME. Then there came S\" which involves buffering.
>> Don't use a buffer - use a buffer. The arguments go around in circles.
> True. I solved it differently: I defined OMIT, which parses leading delimiters. Then I defined PARSE-WORD as:
> : PARSE-WORD DUP OMIT PARSE ;
>
> The TRUE reason for PARSE-NAME is that it has to parse a number of "white space" characters.

AFAIK that was also true for 'BL WORD' under ANS. Some special-cased
BL SKIP/SCAN. My approach was >BLANKS ( a u -- ) which first converts
controls to blanks. It has proven useful for applications unrelated
to the forth parser.

But we digress. I'm happy with WORD not least because FIND still needs
a counted string. The factor of WORD which moves and stores - I've
called it WPACK ( adr len -- adr2 ) - is potentially useful for other
things e.g. SEARCH-WORDLIST. The result from WORD goes into the same
buffer as S" on a shared basis. The latter building up and the former
building down to a maximum of 255+31 chars. There's little I've needed
to do that couldn't be done with : TOKEN BL WORD COUNT ;

On 30/10/2021 08:01, Hugh Aguilar wrote:
> On Thursday, October 28, 2021 at 1:16:15 AM UTC-7, the.bee...@gmail.com wrote:
>> > Way back in 1984 (age 18) as I was transitioning from line-number BASIC
>> > to Forth I knew that PAD was a bad idea.
>> Why? In those days, PAD was just a temp buffer for stuff.
>
> You ask: "Why?" You're an idiot too!
> Anybody who uses PAD is an idiot.

Presumably that includes Moore? Idiocy is using things inappropriately.
Did you?

On Friday, October 29, 2021 at 10:47:28 PM UTC-4, dxforth wrote:
> The TRUE reason for PARSE-NAME is that it has to parse a number of "white space" characters.
> AFAIK that was also true for 'BL WORD' under ANS. Some special-cased
> BL SKIP/SCAN. My approach was >BLANKS ( a u -- ) which first converts
> controls to blanks. It has proven useful for applications unrelated
> to the forth parser.
>
> But we digress. I'm happy with WORD not least because FIND still needs
> a counted string. The factor of WORD which moves and stores - I've
> called it WPACK ( adr len -- adr2 ) - is potentially useful for other
> things e.g. SEARCH-WORDLIST. The result from WORD goes into the same
> buffer as S" on a shared basis. The latter building up and the former
> building down to a maximum of 255+31 chars. There's little I've needed
> to do that couldn't be done with : TOKEN BL WORD COUNT ;

For my hobby system I found it useful to modify Camel Forth and factor out
PARSE-WORD which is then used to make WORD.

: PARSE-WORD ( char -- c-addr u)
DUP SOURCE >IN @ /STRING
ROT SKIP
DROP SOURCE -ROT - MIN 0 MAX >IN !
PARSE
;

: WORD ( char -- c-addr)
PARSE-WORD HERE PLACE
HERE BL OVER COUNT + C! \ append blank character
;

With PARSE-WORD I can choose not to copy to HERE if that's
what I need or use WORD in the traditional way.
(Yes, Camel Forth still appends a BL to the WORD string)

So your TOKEN would become:
: TOKEN ( -- c-addr u) BL PARSE-WORD ;

On 31/10/2021 01:17, Brian Fox wrote:
> On Friday, October 29, 2021 at 10:47:28 PM UTC-4, dxforth wrote:
>> The TRUE reason for PARSE-NAME is that it has to parse a number of "white space" characters.
>> AFAIK that was also true for 'BL WORD' under ANS. Some special-cased
>> BL SKIP/SCAN. My approach was >BLANKS ( a u -- ) which first converts
>> controls to blanks. It has proven useful for applications unrelated
>> to the forth parser.
>>
>> But we digress. I'm happy with WORD not least because FIND still needs
>> a counted string. The factor of WORD which moves and stores - I've
>> called it WPACK ( adr len -- adr2 ) - is potentially useful for other
>> things e.g. SEARCH-WORDLIST. The result from WORD goes into the same
>> buffer as S" on a shared basis. The latter building up and the former
>> building down to a maximum of 255+31 chars. There's little I've needed
>> to do that couldn't be done with : TOKEN BL WORD COUNT ;
>
> For my hobby system I found it useful to modify Camel Forth and factor out
> PARSE-WORD which is then used to make WORD.
>
> : PARSE-WORD ( char -- c-addr u)
> DUP SOURCE >IN @ /STRING
> ROT SKIP
> DROP SOURCE -ROT - MIN 0 MAX >IN !
> PARSE
> ;
>
> : WORD ( char -- c-addr)
> PARSE-WORD HERE PLACE
> HERE BL OVER COUNT + C! \ append blank character
> ;
>
> With PARSE-WORD I can choose not to copy to HERE if that's
> what I need or use WORD in the traditional way.
> (Yes, Camel Forth still appends a BL to the WORD string)

So does mine. If SF couldn't be certain they wouldn't need it again
who am I to know :)

>
> So your TOKEN would become:
> : TOKEN ( -- c-addr u) BL PARSE-WORD ;

I'd be struggling to find a use for PARSE-WORD :)

I factored mine as follows:

: PARSE ( char -- c-addr u ) false (parse) ;
: WORD ( char -- c-addr ) true (parse) wpack ;

(parse) and wpack are currently headerless.

Once S" ," .( etc. are defined, there's probably not a lot of use for PARSE
if my apps are any indication.

On Saturday, October 30, 2021 at 12:15:34 PM UTC-4, dxforth wrote:
> On 31/10/2021 01:17, Brian Fox wrote:
> > On Friday, October 29, 2021 at 10:47:28 PM UTC-4, dxforth wrote:
> >> The TRUE reason for PARSE-NAME is that it has to parse a number of "white space" characters.
> >> AFAIK that was also true for 'BL WORD' under ANS. Some special-cased
> >> BL SKIP/SCAN. My approach was >BLANKS ( a u -- ) which first converts
> >> controls to blanks. It has proven useful for applications unrelated
> >> to the forth parser.
> >>
> >> But we digress. I'm happy with WORD not least because FIND still needs
> >> a counted string. The factor of WORD which moves and stores - I've
> >> called it WPACK ( adr len -- adr2 ) - is potentially useful for other
> >> things e.g. SEARCH-WORDLIST. The result from WORD goes into the same
> >> buffer as S" on a shared basis. The latter building up and the former
> >> building down to a maximum of 255+31 chars. There's little I've needed
> >> to do that couldn't be done with : TOKEN BL WORD COUNT ;
> >
> > For my hobby system I found it useful to modify Camel Forth and factor out
> > PARSE-WORD which is then used to make WORD.
> >
> > : PARSE-WORD ( char -- c-addr u)
> > DUP SOURCE >IN @ /STRING
> > ROT SKIP
> > DROP SOURCE -ROT - MIN 0 MAX >IN !
> > PARSE
> > ;
> >
> > : WORD ( char -- c-addr)
> > PARSE-WORD HERE PLACE
> > HERE BL OVER COUNT + C! \ append blank character
> > ;
> >
> > With PARSE-WORD I can choose not to copy to HERE if that's
> > what I need or use WORD in the traditional way.
> > (Yes, Camel Forth still appends a BL to the WORD string)
> So does mine. If SF couldn't be certain they wouldn't need it again
> who am I to know :)
> >
> > So your TOKEN would become:
> > : TOKEN ( -- c-addr u) BL PARSE-WORD ;
> I'd be struggling to find a use for PARSE-WORD :)
>
> I factored mine as follows:
>
> : PARSE ( char -- c-addr u ) false (parse) ;
> : WORD ( char -- c-addr ) true (parse) wpack ;
>
> (parse) and wpack are currently headerless.
>
> Once S" ," .( etc. are defined, there's probably not a lot of use for PARSE
> if my apps are any indication.

On a "glacial" speed system like 9900 copying to HERE or not can make a
difference in execution speed. So I use PARSE-WORD whenever the data
does not need that extra copying but I want to skip leading blanks.
It's a small hit for WORD calling PARSE-WORD.