S\" question

[dxforth]

Assuming this is implemented by first executing CHAR " PARSE
is there any reason why the conversion can't be done in its own
buffer i.e. TIB ?

I don't have S\" but something like it. I built the new string
piecemeal in a different buffer but no longer recall why :(

[Hans Bezemer]

I can only tell you how 4tH does it. It's supported in the preprocessor.
The string is compiled "as is" and hence placed in the stringbuffer
at runtime. Then (at runtime) the substitutions are made (which can
be done safely, since the string always shrinks in size).

Hans Bezemer

[none albert]

I don't like
S\" aa[e "
notation. It should be
"aa]e"
followed by >\ .

Replacing reverse polish notation with polish notation at a whim,
I consider a bad idea. The c-people do it, is invariably a bad excuse.

There is even this idea, I had, of concatenating a string, with a word
following in a special wordlist.
"Ape". would mean "Ape" TYPE
"Ape".. would mean "Ape" TYPE CR
"Ape"\ would mean S\" Ape"

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

[dxforth]

Checked a couple of implementations. They used a separate buffer
(as I originally did) so I figured there must be a reason. Turns
out a buffer results in less code so no longer critical it be done
in place. Though still curious whether there are reasons not to ...

[dxforth]

On 8/07/2022 19:07, albert wrote:
> ...

> I don't like
> S\" aa[e "
> notation. It should be
> "aa]e"
> followed by >\ .
>
> Replacing reverse polish notation with polish notation at a whim,
> I consider a bad idea. The c-people do it, is invariably a bad excuse.
>
> There is even this idea, I had, of concatenating a string, with a word
> following in a special wordlist.
> "Ape". would mean "Ape" TYPE
> "Ape".. would mean "Ape" TYPE CR
> "Ape"\ would mean S\" Ape"

I don't like S\" either. OTOH I have needed strings of binary values e.g.

: RC$ ( -- a n ) \ row/col string
bin? if [ pad dup off 1 ] sliteral end
s" 000" drop #asc ;

which is both clumsy and ugly.

I didn't need nor want the whole C shebang and figured hex escapes would
do me just fine e.g.

S" \0D\0A\0D\0A\09\09Hello \\ world!\0D\0A\0D\0A"

Hello \ world!

This will be built into S" and ,"

[Hans Bezemer]

On Friday, July 8, 2022 at 12:13:54 PM UTC+2, dxforth wrote:
> I don't like S\" either. OTOH I have needed strings of binary values e.g.

Neither do I. Yeah, sure - I used such escaped strings in a Basic interpreter,
but such occasions are RARE.

> I didn't need nor want the whole C shebang

Well, that kind of irritates me as well. Yeah, sure - dump another bunch of
C-isms in the standard (like LOCALS and FILE wasn't enough). At some point
I don't see anymore why I shouldn't program in C directly - if we ripped enough
features from it.

I created S| for embedding quotes - which tend to happen from time to time.
But I rarely need to encode all kinds of control characters in strings. If I need
control characters, it's often because I need all binary strings. And those are best
served by C,

But stuff like "\t\tstuff\n"? Not really..

Hans Bezemer

[P Falth]

On Friday, 8 July 2022 at 09:55:25 UTC+2, dxforth wrote:
> Assuming this is implemented by first executing CHAR " PARSE
> is there any reason why the conversion can't be done in its own
> buffer i.e. TIB ?

I can think of 2 reasons.
Your source could be read-only.
I have that in LXF when the source is an included file. It is memory-mapped
read-only. Writing to it will give a segmentation fault.

If you split your code on 2 lines like

S\" Hej Peter"
TYPE

The text could be overwritten and lost

Peter

[S Jack]

On Friday, July 8, 2022 at 2:55:25 AM UTC-5, dxforth wrote:
>
> I don't have S\" but something like it. I built the new string
> piecemeal in a different buffer but no longer recall why :(

I typically build strings using MPAD, a string ring buffer, and
operators +S (append string) and +C (append character). The +S and +C
are not restricted to MPAD but can be applied to any buffer. But when
doing IPC and making system writes to fifo, I skip building strings
and just WRITE content directly to the system. The written content
becomes appended naturally due to the system holding it until
a newline is received.
--
me

[minf...@arcor.de]

C makes life easier with open_memstream that provides a dynamic
memory buffer until closed.

[dxforth]

On 9/07/2022 00:46, P Falth wrote:
> On Friday, 8 July 2022 at 09:55:25 UTC+2, dxforth wrote:
>> Assuming this is implemented by first executing CHAR " PARSE
>> is there any reason why the conversion can't be done in its own
>> buffer i.e. TIB ?
>
> I can think of 2 reasons.
> Your source could be read-only.
> I have that in LXF when the source is an included file. It is memory-mapped
> read-only. Writing to it will give a segmentation fault.
>
> If you split your code on 2 lines like
>
> S\" Hej Peter"
> TYPE
>
> The text could be overwritten and lost

Makes sense.

p.s. Thanks for BL-SKIP BL-SCAN :)

[dxforth]

Not least it contradicts CR etc. One accepts a forth system may need to
communicate with a C-based OS but since when are such programs 'standard'?
Then there's the proliferation of S" S\" ," ,\" C" C\" etc. A dependency
on '\' within quoted strings would at least have hidden the C-isms had a
system need to support C escapes. Would it have broken code - possibly
but it would have been rare enough not to matter. Under my 'hex escapes'
old source that had '\' within quotes would likely generate a 'not hex'
error - easy to fix.

[dxforth]

On 9/07/2022 00:42, Hans Bezemer wrote:

> ...

> I created S| for embedding quotes - which tend to happen from time to time.
> But I rarely need to encode all kinds of control characters in strings. If I need
> control characters, it's often because I need all binary strings. And those are best
> served by C,

These two scenarios were exactly mine. The following seemed overkill for just
a 1 character string:

create NUL 0 c,

: RC$ ( -- a n ) \ row/col string

bin? if NUL 1 end
s" 000" drop #asc ;

Similarly S| just to handle the rare case of embedded quote.

Years earlier I happened upon Baden's scheme for embedded quotes. I generalised
it to handle any delimiter - not just quote. However it always bugged me that I
was expending code just for this rare situation - and still I had no solution for
the NUL scenario. That's when I hit upon 'hex escapes' to solve both problems.

Below is the algorithm I used. PAD and S" are just for testing. Most forths will
have something equivalent to C/STRING and >DIGIT in the kernel (albeit unfactored).

\ c/string ( a u -- a+1 u-1 char )
\ >digit ( char base -- u true | char false )

8 ( 255) constant smax \ max string out, buffer size must be smax+1
: sbuf pad ;

: /esc ( a u -- a2 u2 c f )
c/string dup [char] \ = ;

: /nib ( a u -- a2 u2 x )
/esc if unnest end
upcase 16 >digit 0= abort" not hex" ;

: /hb ( a u -- a2 u2 x )
/nib 4 lshift >r /nib r> or ;

\ testing
: s" ( -- a u )
[char] " parse
sbuf 0 begin
2>r dup 0>
while
/esc if drop /hb then 2r@ + c!
2r> 1+ smax min
repeat 2drop 2r>
\ tuck dump cr .
;

[dxforth]

Not to mention the spec for S" etc says to store to a temporary buffer.
I blame it on 'brain fog'. Must be old age as I've yet to contract COVID.

[Anton Ertl]

dxforth <dxf...@gmail.com> writes:
>On 9/07/2022 00:42, Hans Bezemer wrote:
>> But stuff like "\t\tstuff\n"? Not really..
>
>Not least it contradicts CR etc.

What makes you think so? And what do you mean with "etc."?

>One accepts a forth system may need to
>communicate with a C-based OS

What does this have to do with S\"?

>but since when are such programs 'standard'?

If a standard program communicates with a C-based OS, that does not
make it any less standard. Why should the standard preclude
communicating with C-based OSs?

>Then there's the proliferation of S" S\" ," ,\" C" C\" etc.

Is there? Of these, only S" S\" C" are standardized. What do you
mean with etc.?

- 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: https://forth-standard.org/
EuroForth 2022: http://www.euroforth.org/ef22/cfp.html

[dxforth]

On 9/07/2022 19:28, Anton Ertl wrote:
> dxforth <dxf...@gmail.com> writes:
>>On 9/07/2022 00:42, Hans Bezemer wrote:
>>> But stuff like "\t\tstuff\n"? Not really..
>>
>>Not least it contradicts CR etc.
>
> What makes you think so? And what do you mean with "etc."?

There's a need for CR when C-escapes exist?

>
>>One accepts a forth system may need to
>>communicate with a C-based OS
>
> What does this have to do with S\"?

You'll need to be more specific.

>
>>but since when are such programs 'standard'?
>
> If a standard program communicates with a C-based OS, that does not
> make it any less standard. Why should the standard preclude
> communicating with C-based OSs?

What OS specific communication did you have in mind? Certainly
somebody decided the ability to cut C-escapes and paste them into
Forth needed to be standardized.

>
>>Then there's the proliferation of S" S\" ," ,\" C" C\" etc.
>
> Is there? Of these, only S" S\" C" are standardized. What do you
> mean with etc.?

I don't know when SwiftForth introduced them but there they are.

Was it the best choice to have two of everything - or was it forced
upon the Standard because that's what the majors had.

[Anton Ertl]

dxforth <dxf...@gmail.com> writes:
>On 9/07/2022 19:28, Anton Ertl wrote:
>> dxforth <dxf...@gmail.com> writes:
>>>On 9/07/2022 00:42, Hans Bezemer wrote:
>>>> But stuff like "\t\tstuff\n"? Not really..
>>>
>>>Not least it contradicts CR etc.
>>
>> What makes you think so? And what do you mean with "etc."?
>
>There's a need for CR when C-escapes exist?

I'll assume you mean S\" when you write "C-escapes". If CR was not
there, one could work around it with

s\" \n" type

That may be considered a redundancy but it's not a contradiction.

>>>One accepts a forth system may need to
>>>communicate with a C-based OS
>>
>> What does this have to do with S\"?
>
>You'll need to be more specific.

Where do you see the connection between C-based OSs and S\"?

If we used a different notation for specifying control characters in
literal strings, it would be just as easy or just as hard to
communicate with C-based OSs.

>>>but since when are such programs 'standard'?
>>
>> If a standard program communicates with a C-based OS, that does not
>> make it any less standard. Why should the standard preclude
>> communicating with C-based OSs?
>
>What OS specific communication did you have in mind?

I have mainly TYPE and WRITE-FILE in mind. The question is rather:
What do you have in mind? You brought up the "need to communicate
with a C-based OS".

>Certainly
>somebody decided the ability to cut C-escapes and paste them into
>Forth needed to be standardized.

The proposal <http://www.forth200x.org/escaped-strings.html> contains
a problem description. This problem description does not include
anything like "cut C-escapes and paste them into Forth".

>>>Then there's the proliferation of S" S\" ," ,\" C" C\" etc.
>>
>> Is there? Of these, only S" S\" C" are standardized. What do you
>> mean with etc.?
>
>I don't know when SwiftForth introduced them but there they are.

You should take that complaint to the SwiftForth people.

>Was it the best choice to have two of everything - or was it forced
>upon the Standard because that's what the majors had.

Who are the "majors". And what do you mean with "two of everything"
in connection with the standard? As pointed out above, only S" S\" C"
are standardized.

[dxforth]

On 10/07/2022 00:10, Anton Ertl wrote:
> dxforth <dxf...@gmail.com> writes:
>>On 9/07/2022 19:28, Anton Ertl wrote:
>>> dxforth <dxf...@gmail.com> writes:
>>>>On 9/07/2022 00:42, Hans Bezemer wrote:
>>>>> But stuff like "\t\tstuff\n"? Not really..
>>>>
>>>>Not least it contradicts CR etc.
>>>
>>> What makes you think so? And what do you mean with "etc."?
>>
>>There's a need for CR when C-escapes exist?
>
> I'll assume you mean S\" when you write "C-escapes". If CR was not
> there, one could work around it with
>
> s\" \n" type
>
> That may be considered a redundancy but it's not a contradiction.

'Render obsolete' would be closer to the mark.

>>>>One accepts a forth system may need to
>>>>communicate with a C-based OS
>>>
>>> What does this have to do with S\"?
>>
>>You'll need to be more specific.
>
> Where do you see the connection between C-based OSs and S\"?

S\" wasn't introduced to support the C ecosystem?

>>Certainly
>>somebody decided the ability to cut C-escapes and paste them into
>>Forth needed to be standardized.
>
> The proposal <http://www.forth200x.org/escaped-strings.html> contains
> a problem description. This problem description does not include
> anything like "cut C-escapes and paste them into Forth".

It would have been closer to the truth. Had someone come along and
said there was a simpler way of getting the same result, I can
imagine the reaction of the vendors on the committee. Of course it
was about supporting C-escapes. I've no doubt there were many in
the crowd cheering it on too. IIRC I was one of them. C rubbing off
onto Forth could only be for the better.

[Anton Ertl]

dxforth <dxf...@gmail.com> writes:
>On 10/07/2022 00:10, Anton Ertl wrote:
>> dxforth <dxf...@gmail.com> writes:
>>>On 9/07/2022 19:28, Anton Ertl wrote:
>>>> dxforth <dxf...@gmail.com> writes:
>>>>>One accepts a forth system may need to
>>>>>communicate with a C-based OS
>>>>
>>>> What does this have to do with S\"?
>>>
>>>You'll need to be more specific.
>>
>> Where do you see the connection between C-based OSs and S\"?
>
>S\" wasn't introduced to support the C ecosystem?

No. It was introduced to produce arbitrary literal strings.

>>>Certainly
>>>somebody decided the ability to cut C-escapes and paste them into
>>>Forth needed to be standardized.
>>
>> The proposal <http://www.forth200x.org/escaped-strings.html> contains
>> a problem description. This problem description does not include
>> anything like "cut C-escapes and paste them into Forth".
>
>It would have been closer to the truth.

Evidence? I don't remember ever cutting a string with \-escapes from
C code and pasting it into Forth code.

[dxforth]

On 10/07/2022 23:00, Anton Ertl wrote:
> dxforth <dxf...@gmail.com> writes:
>>On 10/07/2022 00:10, Anton Ertl wrote:
>>> dxforth <dxf...@gmail.com> writes:
>>>>On 9/07/2022 19:28, Anton Ertl wrote:
>>>>> dxforth <dxf...@gmail.com> writes:
>>>>>>One accepts a forth system may need to
>>>>>>communicate with a C-based OS
>>>>>
>>>>> What does this have to do with S\"?
>>>>
>>>>You'll need to be more specific.
>>>
>>> Where do you see the connection between C-based OSs and S\"?
>>
>>S\" wasn't introduced to support the C ecosystem?
>
> No. It was introduced to produce arbitrary literal strings.

And to be C compatible.

>>>>Certainly
>>>>somebody decided the ability to cut C-escapes and paste them into
>>>>Forth needed to be standardized.
>>>
>>> The proposal <http://www.forth200x.org/escaped-strings.html> contains
>>> a problem description. This problem description does not include
>>> anything like "cut C-escapes and paste them into Forth".
>>
>>It would have been closer to the truth.
>
> Evidence? I don't remember ever cutting a string with \-escapes from
> C code and pasting it into Forth code.

For my part, I've seen nothing to suggest Forth's use of S\" and friends
has been any different from C's use of escapes.

[minf...@arcor.de]

What a paranoid nonsense.

BTW there a quite a number of differences between C string
escape sequences and Forth S\" subsitution characters.

[S Jack]

On Friday, July 8, 2022 at 2:55:25 AM UTC-5, dxforth wrote:
>

> I don't have S\" but something like it. I built the new string
> piecemeal in a different buffer but no longer recall why :(

Haven't bothered to implement string escapes as I usually build strings
piecemeal. I did in past systems have "/S" which converted a string having
escapes, for example:
s" \e[33mHello World!\e[m" /s type

The _general_ rule was:
Keep strings in escape form; only convert when needed e.g. when typed.

Escape form prevents corrupted views of memory and screen dumps and
also allows safe data exchange.

Of course there are exceptions (rules are meant to be broken).
Text in drop box I keep in expanded form. No wait for escape conversion
needed when box is moved.
--
me

[dxforth]

If you're saying S\" falls well short of what C quoted strings can do,
I agree - in which case why choose the format? In a word - worship.
S\" and sprintf packages are symptomatic of C's influence. Denials
are to be expected given the contradiction Forth was supposed to be
the superior language but is now lacking any principle or imagination.

[dxforth]

On 11/07/2022 04:09, S Jack wrote:
> On Friday, July 8, 2022 at 2:55:25 AM UTC-5, dxforth wrote:
>>
>> I don't have S\" but something like it. I built the new string
>> piecemeal in a different buffer but no longer recall why :(
>
> Haven't bothered to implement string escapes as I usually build strings
> piecemeal. I did in past systems have "/S" which converted a string having
> escapes, for example:
> s" \e[33mHello World!\e[m" /s type
>
> The _general_ rule was:
> Keep strings in escape form; only convert when needed e.g. when typed.
>
> Escape form prevents corrupted views of memory and screen dumps and
> also allows safe data exchange.

C embeds variables in quoted strings, preventing expansion at compile-time.
Forth has very little reason to embed stuff in quotes, controls included.

[none albert]

In article <tag7n0$10ia$1...@gioia.aioe.org>, dxforth <dxf...@gmail.com> wrote:
>On 11/07/2022 03:45, minf...@arcor.de wrote:
>> dxforth schrieb am Sonntag, 10. Juli 2022 um 05:16:57 UTC+2:
>>> On 10/07/2022 00:10, Anton Ertl wrote:

<SNIP>

>>> > The proposal <http://www.forth200x.org/escaped-strings.html> contains
>>> > a problem description. This problem description does not include
>>> > anything like "cut C-escapes and paste them into Forth".
>>> It would have been closer to the truth. Had someone come along and
>>> said there was a simpler way of getting the same result, I can
>>> imagine the reaction of the vendors on the committee. Of course it
>>> was about supporting C-escapes. I've no doubt there were many in
>>> the crowd cheering it on too. IIRC I was one of them. C rubbing off
>>> onto Forth could only be for the better.
>>
>> What a paranoid nonsense.
>>
>> BTW there a quite a number of differences between C string
>> escape sequences and Forth S\" subsitution characters.
>
>If you're saying S\" falls well short of what C quoted strings can do,
>I agree - in which case why choose the format? In a word - worship.
>S\" and sprintf packages are symptomatic of C's influence. Denials
>are to be expected given the contradiction Forth was supposed to be
>the superior language but is now lacking any principle or imagination.

On the other hand mpeforth formatting with % escapes is superior to
what c can do. It is in fact a logical way of thinking in Forth,
I have something similar in ciforth.

[dxforth]

That would be SUBSTITUTE REPLACES from 200x that requires the forth
compiler to work? It didn't suit my needs.

[none albert]

I have the mpeforth implementation not available, but I can
present my own one-screener:
[ in ciforth SUBSTITUTE REPLACES is nowhere to be seen,
not even in loadable extension]

0 ( FORMAT FORMAT&EVAL .FORMAT ) \ AH&CH C2feb15
1 DATA CRS$ 4096 ALLOT \ ":2" WANTED
2 NAMESPACE FORMAT-WID FORMAT-WID DEFINITIONS
3 : c CRS$ $C+ ; : n ^J c ; : r ^M c ; \ Add single char's
4 : d S>D 0 (D.R) CRS$ $+! ; \ Add INT as a string.
5 : s CRS$ $+! ; \ Add a STRING as such.
6 PREVIOUS DEFINITIONS
7 \ Format the first part of STRING, up till %, leave REST.
8 : _plain &% $/ CRS$ $+! ;
9 \ Format X with first word of STRING, up till BL, leave REST.
10 : _format BL $/ 2SWAP >R >R 'FORMAT-WID >WID (FIND) NIP NIP
11 DUP 0= 51 ?ERROR EXECUTE R> R> ;
12 \ Format X1 .. Xn using the format STRING.
13 : FORMAT 0 CRS$ ! BEGIN DUP WHILE _plain DUP IF _format THEN
14 REPEAT 2DROP CRS$ $@ ;
15 : FORMAT&EVAL FORMAT EVALUATE ; : .FORMAT FORMAT TYPE ; l

It is a one screener in the context of a carefully designed Forth,
where the basic words have much functionality and yet are simple.
The idea is simple.
- look up %
- look up the word following % in a specilized wordlist
- execute the word.

EXAMPLE
"KOOS" "%n hello %s !%n" .FORMAT
<newline>
hello KOOS!
<newline>

You can easily add a word \ that do hex escapes to FORMAT-WID
to the effect

"%\ 0D%\ 0Ahoera" .FORMAT

Notes:
NAMESPACE (non-iso) replaces the (non-iso) VOCABULARY.
you may have to load the
$! $@ $+! $C+ $/
wordset, if you are a PLACE PLACE+ person.

[Gerry Jackson]

Nonsense, more likely practicality. Worship in Forth is the word for
acolytes of Charles Moore.

> S\" and sprintf packages are symptomatic of C's influence.

Given that C style escapes and sprintf have been adopted by several
other languages, there's a lot of merit in having them available in
Forth because of their familiarity. Dismissing them due to a narrow-
minded dogma is silly or worse.

> Denials
> are to be expected given the contradiction Forth was supposed to be
> the superior language but is now lacking any principle or imagination.

More nonsense.

--
Gerry

[Hans Bezemer]

On Monday, July 11, 2022 at 2:28:43 PM UTC+2, Gerry Jackson wrote:
> Nonsense, more likely practicality. Worship in Forth is the word for
> acolytes of Charles Moore.

If you mean "quick and dirty (and lazy) programming" I completely agree
with you. And yes, in every language you got fundamentalists and pragmatics.
Forth is no different. But like most things in life, there are more than two
categories.

> > S\" and sprintf packages are symptomatic of C's influence.
> Given that C style escapes and sprintf have been adopted by several
> other languages, there's a lot of merit in having them available in
> Forth because of their familiarity.

That's real BS - and I will tell you why. If you're talking about programmers
that come in from C-like languages you might be true. However, it has been
well established over the years that those write horrible Forth. Adding C stuff
in Forth re-enforces those BAD habits - because if it looks like it, it must be
something like it. And we all know that's definitely not true.

> Dismissing them due to a narrow-minded dogma is silly or worse.
Since you provide absolutely zero arguments why this would be true, I tend
to dismiss this statement as "unfounded" and "without merit".

> > Denials are to be expected given the contradiction Forth was supposed to be
> > the superior language but is now lacking any principle or imagination.
> More nonsense.

I don't think this is wrong. C-isms have been steadily been creeping into Forth - and
S\" is just one of them. The LOCALS and FILE wordset are a few other examples.

The simple fact that we, as a community, have been unable to come up with any
Forth-like alternative is somewhat worrying.

These C-isms are absolutely alien to the Forth canon. In Forth terms they require
an excessive amount of code - and I know, because I've been writing them. Not
to introduce C-isms but more as an exercise "how difficult can it be". But I rarely use
them, unless "I'm in a hurry" (like work). Frankly, because I don't like the use of massive
libraries in my programs. Because there are almost always better ways to do it.

And that what's distinguishes a Forth programmer from a Python programmer IMHO.

You don't have to agree with me. But I think you dismiss dxforth's arguments a bit
too easily - with a bit too much emotion and too few arguments.

Hans Bezemer

[dxforth]

It puzzles me how any of this ended up in a Forth Standard. It befits
http://theforth.net/ That it can't be implemented portably shouldn't
have been made everybody's problem. Did nobody object at the time?

Getting back to the point you were trying to make. I don't believe
Forth is about cleverness. Rather it's programmer-implementers being
realistic as to needs and costs. In a language that's user-extensible
it's paramount else chaos will surely result. I struggle with it
every day. Still I get it wrong, have to go back and correct. AFAIK
Moore never wanted followers, or to sit on a committee. Perhaps for
the same reasons. To borrow a phrase 'Forth is a pathless land'.

[dxforth]

Perhaps you've never seen the Temple of ANS:

https://forth-standard.org/

>
>> S\" and sprintf packages are symptomatic of C's influence.
>
> Given that C style escapes and sprintf have been adopted by several
> other languages, there's a lot of merit in having them available in
> Forth because of their familiarity. Dismissing them due to a narrow-
> minded dogma is silly or worse.
>
>> Denials
>> are to be expected given the contradiction Forth was supposed to be
>> the superior language but is now lacking any principle or imagination.
>
> More nonsense.

Take it up with Anton. It was he denying S\" had anything to do with C.

[dxforth]

On 12/07/2022 02:20, Hans Bezemer wrote:
>
> The simple fact that we, as a community, have been unable to come up with any
> Forth-like alternative is somewhat worrying.

Ever since ANS nobody has been willing to contradict it. One could say
ANS got its wish. Moore said all innovation would be quashed. It's been
replaced with authorized hand-me-downs.

[Hans Bezemer]

Recent discussions have strengthened my suspicion that Forth 200x has been
hijacked by a few vendors and academics who push forward their own pet ideas
and have in effect lost (or abandoned) the community surrounding it.

After a few wordsets that IMHO lack any general use and should be considered
to be libraries rather than wordsets and a few other proposals that repeat the
errors of Forth-83, I've stopped to frenetically follow the Forth-200x "standard".

If I can, I will - but I won't bend over backwards to keep up. ANS-94 is good enough
for me in that regard.

Hans Bezemer

[minf...@arcor.de]

the.bee...@gmail.com schrieb am Dienstag, 12. Juli 2022 um 10:08:31 UTC+2:
> On Tuesday, July 12, 2022 at 6:14:51 AM UTC+2, dxforth wrote:
> > On 12/07/2022 02:20, Hans Bezemer wrote:
> > >
> > > The simple fact that we, as a community, have been unable to come up with any
> > > Forth-like alternative is somewhat worrying.
> > Ever since ANS nobody has been willing to contradict it. One could say
> > ANS got its wish. Moore said all innovation would be quashed. It's been
> > replaced with authorized hand-me-downs.
> Recent discussions have strengthened my suspicion that Forth 200x has been
> hijacked by a few vendors and academics who push forward their own pet ideas
> and have in effect lost (or abandoned) the community surrounding it.

To remain fair: the 200x group invites any person to participate and to push forward
her/his own great or little proposals. You call this hijacking?

As to your complaining about some group members "pushing forward" too much,
I have the opposite impression. Ideas like recognizers or to clean up dual-semantics
didn't really get through. You call this pushing?

Don't become as paranoid as some other c.l.f posters in the past.

[dxforth]

How is giving up on 200x being paranoid? After near two decades
of 200x, anyone who hasn't formed an opinion on it, never will.

[Gerry Jackson]

Well said,


--
Gerry

[S Jack]

The standard "\z" conflicts with my z-codes; it will have to change.
--
me

[Gerry Jackson]

On 11/07/2022 17:20, Hans Bezemer wrote:
> On Monday, July 11, 2022 at 2:28:43 PM UTC+2, Gerry Jackson wrote:
>> Nonsense, more likely practicality. Worship in Forth is the word for
>> acolytes of Charles Moore.
> If you mean "quick and dirty (and lazy) programming"

Without wishing to be rude, just honest, that's what I thought about
your implementation of REPLACE-ALL a few weeks ago.

> I completely agree
> with you. And yes, in every language you got fundamentalists and pragmatics.
> Forth is no different. But like most things in life, there are more than two
> categories.

I think you over-snipped there, destroying the link between dxforth's
statemenet and my response

>
>>> S\" and sprintf packages are symptomatic of C's influence.
>> Given that C style escapes and sprintf have been adopted by several
>> other languages, there's a lot of merit in having them available in
>> Forth because of their familiarity.
> That's real BS - and I will tell you why. If you're talking about programmers
> that come in from C-like languages you might be true. However, it has been
> well established over the years that those write horrible Forth. Adding C stuff
> in Forth re-enforces those BAD habits - because if it looks like it, it must be
> something like it. And we all know that's definitely not true.

THat's one way of looking at it and my comment has little to do with
good or bad Forth. What I meant was that if, say, I wanted to use a
regular expression package and I was familiar with regex syntax from
using another language like PHP, PERL, C ... and such a package already
exists in Forth, then it makes sense for me to use that package as long
as it works. Now that package may be written in good or bad Forth which
is another issue. Similarly the printf family ans other tools.

>
>> Dismissing them due to a narrow-minded dogma is silly or worse.
> Since you provide absolutely zero arguments why this would be true, I tend
> to dismiss this statement as "unfounded" and "without merit".

I tend to regard it as self-evident.

>
>>> Denials are to be expected given the contradiction Forth was supposed to be
>>> the superior language but is now lacking any principle or imagination.
>> More nonsense.
> I don't think this is wrong. C-isms have been steadily been creeping into Forth - and
> S\" is just one of them. The LOCALS and FILE wordset are a few other examples.

Well locals and the file wordset are not just C-isms, I would guess that
most languages have locals and similar file operations and so, at least
for the latter, familiarity still applies. Now before you blow a gasket
let me say that I hardly ever use locals, the first ANS attempt was
abominable but has been improved by Forth 2012. However, IIRC, it was a
lot of work to implement them so I'm not over-impressed with them. Also
I thought your 4th's file handling words are a good approach.

>
> The simple fact that we, as a community, have been unable to come up with any
> Forth-like alternative is somewhat worrying.

Well have you tried or taken part in RfD discussions to disagree or
propose alternatives.

>
> These C-isms

what other C-isms in the standard? Off the top of my head, I can only
think of character syntax e.g. 'X' which is trivial to implement and
easier to write than CHAR X or [CHAR] X. Of other Forth 2012 words, I
think SUBSTITUTE is awful and over complicated. Also I think ANS Forth
could be greatly improved by pruning/rationalising stuff inherited from
early Forths that are there because of resource limited computers in the
1970/80s.

> are absolutely alien to the Forth canon. In Forth terms they require
> an excessive amount of code - and I know, because I've been writing them. Not
> to introduce C-isms but more as an exercise "how difficult can it be". But I rarely use
> them, unless "I'm in a hurry" (like work). Frankly, because I don't like the use of massive
> libraries in my programs.

Do you distinguish between a library and a tool? I regard a regex or
printf package, with essentially single functionality, as a tool, not a
library with multiple functionality.

> Because there are almost always better ways to do it.

Since you provide absolutely zero arguments why this would be true, I

tend to dismiss this statement as "unproven" :)

Having echoed you, your 'better ways ..." comment is true for lots of
software and not just Forth. But then again "better ways" can mean
different things.


--
Gerry

[dxforth]

On 13/07/2022 00:47, S Jack wrote:
> The standard "\z" conflicts with my z-codes; it will have to change.

s" \z" s" invalid quote

It now stands at three. Are you scared yet?

[Hans Bezemer]

On Tuesday, July 12, 2022 at 11:48:43 AM UTC+2, minf...@arcor.de wrote:
> To remain fair: the 200x group invites any person to participate and to push forward
> her/his own great or little proposals. You call this hijacking?

In Holland we had a "referendum law". Anyone could put forward their proposal. In end
effect the results were discarded and finally the whole thing was repealed.

In short, that you can present your own proposals doesn't mean a lot when others
control the process.

> As to your complaining about some group members "pushing forward" too much,
> I have the opposite impression. Ideas like recognizers or to clean up dual-semantics
> didn't really get through. You call this pushing?

After all the discussions here and all the proponents going into great length to push
this ghastly (un-Forth like) proposal I'm even surprised it never got to a CfV.

> Don't become as paranoid as some other c.l.f posters in the past.

"Paranoid" means fear that people are out to get you specifically. I've learned two
things in life: (a) don't try to explain with "conspiracy" what can equally be explained
with stupidity and (b) people can't be trusted - especially in large groups where they
tend to get even more stupid.

I wouldn't call that "paranoid" by any definition. Misanthropy, perhaps. Ludwig
Wittgenstein, Friedrich Nietzsche, Martin Heidegger, Søren Kierkegaard,
Jean-Paul Sartre, Franz Kafka, Oscar Wilde - I consider myself to be in excellent
company..

Hans Bezemer

[Hans Bezemer]

On Tuesday, July 12, 2022 at 11:12:01 PM UTC+2, Gerry Jackson wrote:
> Without wishing to be rude, just honest, that's what I thought about
> your implementation of REPLACE-ALL a few weeks ago.

It's always nice to see people starting their rebuttal with a well-meant
compliment..

> I think you over-snipped there, destroying the link between dxforth's
> statemenet and my response

.. and unrelated remarks and diversions.

> What I meant was that if, say, I wanted to use a
> regular expression package and I was familiar with regex syntax from
> using another language like PHP, PERL, C ... and such a package already
> exists in Forth, then it makes sense for me to use that package as long
> as it works.

No, it doesn't - unless you're porting that particular PHP, Perl or C program
to Forth and need it to preserve a certain functionality. I myself got some
lightweight regex libraries and I've used them only once. Because regexes
are built to recognize certain patterns. They "compile" or interpret an
expression. I thought I could bypass the whole shebang an wrought a package
that could recognize patterns in Forth using Forth an bypassing that
extra engine.

> >> Dismissing them due to a narrow-minded dogma is silly or worse.
> > Since you provide absolutely zero arguments why this would be true, I tend
> > to dismiss this statement as "unfounded" and "without merit".
> I tend to regard it as self-evident.

Ok, we're getting in ontology territory here. You wanted it, here we go:
(a) Precisely quote the principle and prove its origin;
(b) Prove it is untrue;
(c) Prove that is is a dogma, given that the definition of a dogma is "a principle
or set of principles laid down by an authority as incontrovertibly true";
(d) Define "silly" and levels of "silly" (since it's "worse")
(e) Prove that (given a thru c is true) the application of d is appropriate.

I wouldn't call that "self-evident".

> Well locals and the file wordset are not just C-isms, I would guess that
> most languages have locals and similar file operations and so, at least
> for the latter, familiarity still applies.

Find a language that cannot be traced back to Algol in some way. Forth is
NOT a descendant of Algol, so this cannot apply to Forth. It's built on
entirely different principles. It's comparing trains to cars. Even driven a
train and wondered where the steering wheel was?

> Now before you blow a gasket
> let me say that I hardly ever use locals, the first ANS attempt was
> abominable but has been improved by Forth 2012. However, IIRC, it was a
> lot of work to implement them so I'm not over-impressed with them.

What you do or don't do is irrelevant unless you can illustrate a principle you
put forward. I can (and have) written several articles on NOT using locals and
getting results in Forth without too much stack acrobatics.

I DO support locals in 4tH (although in a slightly different way), but I very
rarely use them - and NEVER in libraries, because I think they're basically
wrong in a Forth context.

> Also I thought your 4th's file handling words are a good approach.

Flattery will get you nowhere ;-)
I consider it to be a "fortunate accident", given their history. It simply began
as a "redirection" issue and it required a lost of thought to turn it into something
that didn't break too much code and still was architecturally sound.

> > The simple fact that we, as a community, have been unable to come up with any
> > Forth-like alternative is somewhat worrying.
> Well have you tried or taken part in RfD discussions to disagree or
> propose alternatives.

In the old days those took place HERE. And like I said: I basically gave up on
Forth 200x. If there is a CfV I will still participate, though.

> what other C-isms in the standard? Off the top of my head, I can only
> think of character syntax e.g. 'X' which is trivial to implement and
> easier to write than CHAR X or [CHAR] X. Of other Forth 2012 words, I
> think SUBSTITUTE is awful and over complicated. Also I think ANS Forth
> could be greatly improved by pruning/rationalising stuff inherited from
> early Forths that are there because of resource limited computers in the
> 1970/80s.

It's C. It's irrelevant whether it is easy to write or not - it's not Forth. My
argument for that is simple. Forth is simple - and hence elegant. If I have
to implement something that breaks that simplicity (and hence its elegance)
I'm NOT going to implement that.

In my recent YouTube I show how simple and elegant Forth's tokenizer and
parser is. Things like 'X' break that internal simplicity - it makes my parser much
more complex. CHAR is a parsing word - and fits perfectly into that scheme.
F% could also be a parsing word for a float. D% could be a parsing word for
a double. No need for recognizers there (which are just UGLY hooks). They
fit the original schema and make the language perfectly expandable.

C-isms break that scheme and require lots of (often ugly) code to implement.

> Do you distinguish between a library and a tool? I regard a regex or
> printf package, with essentially single functionality, as a tool, not a
> library with multiple functionality.
> > Because there are almost always better ways to do it.
> Since you provide absolutely zero arguments why this would be true, I
> tend to dismiss this statement as "unproven" :)

You ask me to distinguish between a tool and a library and then go on to
speak of packages. But ok:
- A library is a set of words that cover one particular field of functionality
that can optionally be added to a program or be part of another library;
- A program is a piece of software that can be executed by a CPU or
another program and provides a certain functionality. A program may
rely on dynamically or statically linked libraries and require other
(non-executable) files in order to function properly.
- An application is a set of programs which provides a set of functionalities,
usually tied to a business process;
- A tool is an application or program targeted to administering or aiding
to the administering of IT services;
- A package is a set of libraries and/or programs intended to be installed
on a particular system.

So yes, regex, printf - all libraries. But very unForth-like libraries. And that
brings us back to square one.

> Having echoed you, your 'better ways ..." comment is true for lots of
> software and not just Forth. But then again "better ways" can mean
> different things.

Better ways: "A style of programming that is better suited to align with
the principles of Forth - or programming in general by requiring less code
and boasting a better performance without the loss of end user functionality".

Happy?

Hans Bezemer

[none albert]

In article <ff629506-901f-4e5e...@googlegroups.com>,

Hans Bezemer <the.bee...@gmail.com> wrote:
>On Tuesday, July 12, 2022 at 11:12:01 PM UTC+2, Gerry Jackson wrote:
>> what other C-isms in the standard? Off the top of my head, I can only
>> think of character syntax e.g. 'X' which is trivial to implement and
>> easier to write than CHAR X or [CHAR] X. Of other Forth 2012 words, I
>> think SUBSTITUTE is awful and over complicated. Also I think ANS Forth
>> could be greatly improved by pruning/rationalising stuff inherited from
>> early Forths that are there because of resource limited computers in the
>> 1970/80s.
>It's C. It's irrelevant whether it is easy to write or not - it's not Forth. My
>argument for that is simple. Forth is simple - and hence elegant. If I have
>to implement something that breaks that simplicity (and hence its elegance)
>I'm NOT going to implement that.

The same for me. I favor a & that is a state-smart CHAR/[CHAR] .
But then I have PREFIX. & is a prefix. &A is a unit that
- is a compile time constant
- is compiled are interpreted like any other number, so that the
compile/interpret distinction, an exception for numbers, is
valid.

Bottom line &A is just another way to get at hex 40.
I'm perfectly okay with that, and guess what?
The resulting Forth is simpler, not more complicated that non-prefix
Forth, because numbers can be treated in this uniform way.

>
>In my recent YouTube I show how simple and elegant Forth's tokenizer and
>parser is. Things like 'X' break that internal simplicity - it makes my
>parser much
>more complex.

Don't implement then. It flies in the face of the normal use of '.

CHAR is a parsing word - and fits perfectly into that scheme.

>F% could also be a parsing word for a float. D% could be a parsing word for
>a double. No need for recognizers there (which are just UGLY hooks). They
>fit the original schema and make the language perfectly expandable.

Make 0 1 2 3 4 5 6 7 8 9 parsing words for numbers and you're done.

<SNIP>

>So yes, regex, printf - all libraries. But very unForth-like libraries. And that
>brings us back to square one.

Something as a file tools is indispensable. The c proposal with
open/read/write/close is palatable.

Regards printf, see the one screen I published that covers 90
(or 99) of the functionality of c string formatting.
Maybe enhanced with >FLOAT.

>Better ways: "A style of programming that is better suited to align with
>the principles of Forth - or programming in general by requiring less code
>and boasting a better performance without the loss of end user functionality".

I like that.
>
>Happy?
>
>Hans Bezemer

[dxforth]

On 13/07/2022 19:09, albert wrote:
> In article <ff629506-901f-4e5e...@googlegroups.com>,
> Hans Bezemer <the.bee...@gmail.com> wrote:
>>On Tuesday, July 12, 2022 at 11:12:01 PM UTC+2, Gerry Jackson wrote:
>>> what other C-isms in the standard? Off the top of my head, I can only
>>> think of character syntax e.g. 'X' which is trivial to implement and
>>> easier to write than CHAR X or [CHAR] X. Of other Forth 2012 words, I
>>> think SUBSTITUTE is awful and over complicated. Also I think ANS Forth
>>> could be greatly improved by pruning/rationalising stuff inherited from
>>> early Forths that are there because of resource limited computers in the
>>> 1970/80s.
>>It's C. It's irrelevant whether it is easy to write or not - it's not Forth. My
>>argument for that is simple. Forth is simple - and hence elegant. If I have
>>to implement something that breaks that simplicity (and hence its elegance)
>>I'm NOT going to implement that.
>
> The same for me. I favor a & that is a state-smart CHAR/[CHAR] .
> But then I have PREFIX. & is a prefix. &A is a unit that
> - is a compile time constant
> - is compiled are interpreted like any other number, so that the
> compile/interpret distinction, an exception for numbers, is
> valid.

This stuff about 'A' being easier to use than CHAR [CHAR] is an old
chestnut. Let's give Forth some credit for having a brain. Does anyone
honestly believe that if using the latter was actually a problem that
Forth wouldn't have found something shorter?

The beauty of CHAR [CHAR] lies in the definition - it's absolutely Forth.
Something that a user from another language wouldn't know or care.
What does it say when Forth sells itself out such users so cheaply.

BTW before ANS it was ASCII [ASCII] - yes, a whole character longer -
how on earth did Forth Inc manage :)

[Hans Bezemer]

On Wednesday, July 13, 2022 at 11:10:02 AM UTC+2, none albert wrote:
> Regards printf, see the one screen I published that covers 90
> (or 99) of the functionality of c string formatting.
> Maybe enhanced with >FLOAT.

I took me a while to figure out your "special words", but I've managed to craft a 4tH version.
I'm not making excuses for "special words" - unless we all do and then I'll plead GUILTY
with full conviction!

---8<---
include lib/scanskip.4th
include lib/ctos.4th
include lib/cstring.4th
include lib/baseexec.4th
\ include lib/anstools.4th

1024 buffer: (crs)

:token (str) dup abs <# #s sign #> ;

: (specify) ( x1 c -- x2)
case
[char] c of c>s endof
[char] d of (str) 10 base&exec endof
[char] n of 10 c>s endof
[char] o of (str) 8 base&exec endof
[char] r of 13 c>s endof
[char] x of (str) 16 base&exec endof
[char] % of s" %" endof
endcase (crs) +place
;

\ Format the first part of STRING, up till %, leave REST.

: (plain) [char] % split (crs) +place chop ;

\ Format X with first word of STRING, up till BL, leave REST.

: (format) c/string -rot 2>r (specify) 2r> ;

\ Format X1 .. Xn using the format STRING.

: format 0 (crs) c!
begin dup 0> while (plain) dup 0> if (format) then repeat
2drop (crs) count ;
: .format format type ;

s" world!" -155 s" hello" 33 s" %c%%bla%%%sbla : %o %s%n" .format
---8<--
$ pp4th -x format.4th
!%bla%hellobla : -233 world!
---8<---

The weakest point of ALL these is the buffer. Yeah, you can do
a full 2 giggles of buffer - but somebody may overflow it still.
Note I'm guilty here as well - my implementations have the very
same problem - except this one (since it only prints - the others
are technically sprintf() implementations).

---8<---
\ This tiny printf() implementation supports the following formats:

\ %{width}d = print an integer in field {width}, right aligned
\ %{width}s = print a string in field {width}, left aligned
\ %c = print a character
\ %% = print a percent character

\ {width} is optional, * is supported

[UNDEFINED] printf [IF]
[UNDEFINED] .padding [IF] include lib/padding.4th [THEN]

variable (width) \ width of field
\ print a special field
: (format) ( a1 n1 -- a2 n2)
dup 0> if \ return on null string
over swap 2>r c@ >r \ save format and character
r@ [char] % = if ." %" then \ print percent
r@ [char] d = if (width) @ .r then \ print number
r@ [char] c = if emit then \ print character or string
r@ [char] s = if (width) @ .padding then
r> [char] * = if (width) ! 2r> chop recurse else 2r> then
then \ recurse if width on command line
;

: (.field) ( x | - a1 n1 -- a2 n2)
0 (width) ! begin \ start with a zero width
chop dup \ get rid of the percent sign
while \ is there any format string left?
over c@ [char] 0 - dup max-n and 10 <
if (width) @ 10 * + (width) ! else drop (format) exit then
repeat \ get width or print format
;
( a n -- a n)
: (%?) over c@ [char] % = if (.field) else over c@ emit then ;
: printf begin dup 0> while (%?) chop repeat 2drop ;
( x1 .. xi a n --)
[DEFINED] 4TH# [IF]
hide (width)
hide (format)
hide (.field)
hide (%?)
[THEN]
[THEN]

\ 23 4 s" Hello" char !
\ s" This is %%char%c%%, string %6s and number%*d" printf cr
---8<---

Still - whatever you throw at it, however small - it doesn't feel like Forth,
but rather a lousy imitation of C.

Hans Bezemer

[S Jack]

My 3g phone quit working first of July; had to upgrade to 5g so now have
"smart" phone. Been several WTFs getting to know it. Just downloaded gForth
to try standard s" \z" and WTF, no backslash on android standard terminal.
This is just a bitch; not looking for recommendations. I know of apps I
can _purchase_ to allow my chromebook to mirror the android (think not.)
--
me

[Hans Bezemer]

On Wednesday, July 13, 2022 at 2:49:55 PM UTC+2, Hans Bezemer wrote:
> On Wednesday, July 13, 2022 at 11:10:02 AM UTC+2, none albert wrote:

Some nice statistics on our printf() implementations:
- Your FORMAT and my PRINTF clock in at about the same number of 4tH words: 200;
- My SPRINTF implementation requires 300 4tH words - but it makes up for that by
a more elaborate "width" functionality:

%{-}{width}d = print a signed decimal integer in field {width}
%{-}{width}u = print an unsigned decimal integer in field {width}
%{-}{width}x = print an unsigned hexadecimal integer in field {width}
%{-}{width}o = print an unsigned octal integer in field {width}
%{-}{width}s = print a string in field {width}

%c = print a character
%% = print a percent character

{width} is optional, * is supported

It seems that's the order of magnitude that this kind of functionality requires.
But feel free to surprise me. ;-)

Hans Bezemer

[dxforth]

Forth on Android? Got as far as installing it and thinking that's nice,
then deleting it.

https://youtu.be/LCRZZC-DH7M

[dxforth]

As if Forth needs more C programmers. There's already the view Forth is
something one builds on top of C. Is it any wonder they thought ANS locals
were backwards and needed to be overturned. America has SCOTUS. Forth has
200x.

[Gerry Jackson]

I'm not wasting my time responding responding in detail to your mixture
of Forth purism and claptrap.


--
Gerry

[Gerry Jackson]

On 13/07/2022 13:49, Hans Bezemer wrote:

> \ 23 4 s" Hello" char !

( -- n1 n2 caddr u ch )

> \ s" This is %%char%c%%, string %6s and number%*d" printf cr

ch caddr u n2 n1

So the order of items on the stack is reversed compared to the left to
right order in the regular expression. ANS Forth made that mistake with
locals.

> ---8<---
>
> Still - whatever you throw at it, however small - it doesn't feel like Forth,

Hardly surprising, regular expressions are a domain specific language
for recognising patterns in text


--
Gerry

[dxforth]

On 14/07/2022 17:39, Gerry Jackson wrote:
> On 13/07/2022 13:49, Hans Bezemer wrote:
>
>> \ 23 4 s" Hello" char !
> ( -- n1 n2 caddr u ch )
>> \ s" This is %%char%c%%, string %6s and number%*d" printf cr
> ch caddr u n2 n1
>
> So the order of items on the stack is reversed compared to the left to
> right order in the regular expression. ANS Forth made that mistake with
> locals.

Forth Inc has never used anything but ANS locals.
But ... but ... how did they handle Windows API calls? :)

[none albert]

In article <taopu1$14kb$1...@gioia.aioe.org>, dxforth <dxf...@gmail.com> wrote:
>On 14/07/2022 17:39, Gerry Jackson wrote:
>> On 13/07/2022 13:49, Hans Bezemer wrote:
>>
>>> \ 23 4 s" Hello" char !
>> ( -- n1 n2 caddr u ch )
>>> \ s" This is %%char%c%%, string %6s and number%*d" printf cr
>> ch caddr u n2 n1
>>
>> So the order of items on the stack is reversed compared to the left to
>> right order in the regular expression. ANS Forth made that mistake with
>> locals.
>
>Forth Inc has never used anything but ANS locals.
>But ... but ... how did they handle Windows API calls? :)

The system used in ciforth is explained in
https://github.com/albertvanderhorst/ciforth/wiki/DLL
and more in
DLL-calls,-the-internal-working

[Gerry Jackson]

On 14/07/2022 11:08, dxforth wrote:
> On 14/07/2022 17:39, Gerry Jackson wrote:
>> On 13/07/2022 13:49, Hans Bezemer wrote:
>>
>>> \ 23 4 s" Hello" char !
>> ( -- n1 n2 caddr u ch )
>>> \ s" This is %%char%c%%, string %6s and number%*d" printf cr
>> ch caddr u n2 n1
>>
>> So the order of items on the stack is reversed compared to the left to
>> right order in the regular expression. ANS Forth made that mistake with
>> locals.
>
> Forth Inc has never used anything but ANS locals.

But they managed to get the 'right' order of arguments in their
implementation of printf

> But ... but ... how did they handle Windows API calls? :)
>
>>
>>> ---8<---
>>>
>>> Still - whatever you throw at it, however small - it doesn't feel like Forth,
>>
>> Hardly surprising, regular expressions are a domain specific language
>> for recognising patterns in text
>>
>>
>

--
Gerry

[none albert]

In article <taou9b$2mrf8$1...@dont-email.me>,

Gerry Jackson <do-no...@swldwa.uk> wrote:
>On 14/07/2022 11:08, dxforth wrote:
>> On 14/07/2022 17:39, Gerry Jackson wrote:
>>> On 13/07/2022 13:49, Hans Bezemer wrote:
>>>
>>>> \ 23 4 s" Hello" char !
>>> ( -- n1 n2 caddr u ch )
>>>> \ s" This is %%char%c%%, string %6s and number%*d" printf cr
>>> ch caddr u n2 n1
>>>
>>> So the order of items on the stack is reversed compared to the left to
>>> right order in the regular expression. ANS Forth made that mistake with
>>> locals.
>>
>> Forth Inc has never used anything but ANS locals.
>
>But they managed to get the 'right' order of arguments in their
>implementation of printf

With the plethora of arguments it hardly helps of the arguments
are in the right order. My solution is superior.
>
>--
>Gerry

[Gerry Jackson]

On 14/07/2022 13:08, albert wrote:
> In article <taou9b$2mrf8$1...@dont-email.me>,
> Gerry Jackson <do-no...@swldwa.uk> wrote:
>> On 14/07/2022 11:08, dxforth wrote:
>>> On 14/07/2022 17:39, Gerry Jackson wrote:
>>>> On 13/07/2022 13:49, Hans Bezemer wrote:
>>>>
>>>>> \ 23 4 s" Hello" char !
>>>> ( -- n1 n2 caddr u ch )
>>>>> \ s" This is %%char%c%%, string %6s and number%*d" printf cr
>>>> ch caddr u n2 n1
>>>>
>>>> So the order of items on the stack is reversed compared to the left to
>>>> right order in the regular expression. ANS Forth made that mistake with
>>>> locals.
>>>
>>> Forth Inc has never used anything but ANS locals.
>>
>> But they managed to get the 'right' order of arguments in their
>> implementation of printf
>
> With the plethora of arguments it hardly helps of the arguments
> are in the right order. My solution is superior.

What's your solution?


--
Gerry

[Hans Bezemer]

On Thursday, July 14, 2022 at 1:22:21 PM UTC+2, Gerry Jackson wrote:
> > Forth Inc has never used anything but ANS locals.
> But they managed to get the 'right' order of arguments in their
> implementation of printf

Yeah, <# #S SIGN #> is "the right order".

1 2 3 4 5 . . . . . 5 4 3 2 1 is "the right order".

Your mind is SO C-geared, you really can't comprehend the dynamics of a LIFO stack anymore.

Hans Bezemer

[Gerry Jackson]

On 14/07/2022 16:30, Hans Bezemer wrote:
> On Thursday, July 14, 2022 at 1:22:21 PM UTC+2, Gerry Jackson wrote:
>>> Forth Inc has never used anything but ANS locals.
>> But they managed to get the 'right' order of arguments in their
>> implementation of printf
> Yeah, <# #S SIGN #> is "the right order".

So what? Given the specs for pictured output of course it is

>
> 1 2 3 4 5 . . . . . 5 4 3 2 1 is "the right order".
>
> Your mind is SO C-geared, you really can't comprehend the dynamics of a LIFO stack anymore.

I don't think so, I believe in making life easier for the user of
software. As demonstrated by the support for the Forth 2012 change to
the order of loading locals, people prefer items appearing on the stack
in the same order as the declarations - similar to my preference for printf.

If we're into making generalisations about each other on little
evidence, you are so fixated on elegance and beauty of Forth that you
don't care about user experience, possibly even contemptuous about it,
they have to live with it.


--
Gerry

[dxforth]

On 14/07/2022 21:22, Gerry Jackson wrote:
> On 14/07/2022 11:08, dxforth wrote:
>> On 14/07/2022 17:39, Gerry Jackson wrote:
>>> On 13/07/2022 13:49, Hans Bezemer wrote:
>>>
>>>> \ 23 4 s" Hello" char !
>>> ( -- n1 n2 caddr u ch )
>>>> \ s" This is %%char%c%%, string %6s and number%*d" printf cr
>>> ch caddr u n2 n1
>>>
>>> So the order of items on the stack is reversed compared to the left to
>>> right order in the regular expression. ANS Forth made that mistake with
>>> locals.
>>
>> Forth Inc has never used anything but ANS locals.
>
> But they managed to get the 'right' order of arguments in their
> implementation of printf

Didn't look that far. I saw it as an attempt to impress C programmers.
in much the same way as Moore did with his BASIC compiler i.e. 'proof
of concept' rather than for serious use.

[Hans Bezemer]

On Thursday, July 14, 2022 at 9:10:41 PM UTC+2, Gerry Jackson wrote:
> > Your mind is SO C-geared, you really can't comprehend the dynamics of a LIFO stack anymore.
> I don't think so, I believe in making life easier for the user of
> software. As demonstrated by the support for the Forth 2012 change to
> the order of loading locals, people prefer items appearing on the stack
> in the same order as the declarations - similar to my preference for printf.

Well, by stating that you actually confirm what I'm saying. Take a language, strip
all infix notation, all stack frames and all syntax and what you're left with is Forth.
Forth wasn't intended to be about "making it easier for the programmer" it was
intended to be powerful in its utter simplicity. Sure, it won't be "easy for the
programmer" - because we threw away all that.

It's the completely inverse philosophy of Java, which was created to allow
people to program who shouldn't even get near to a compiler in their lives.
Forth, however, was built to be used by people born to be a programmer.

> If we're into making generalisations about each other on little
> evidence, you are so fixated on elegance and beauty of Forth that you
> don't care about user experience, possibly even contemptuous about it,
> they have to live with it.

Yeah, you always got that class of people who want to belong to the "cool
crowd" and blame the language doesn't provide all those things they so
desperately require in order to wrap their tiny brains around it. And even
with those things their work is still awful. And I really mean "abysmal". I've
blogged several times about those things.

To those people I'd like to say "Forth is not for everyone. It is fine as it is.
But it may not be for you. There are lots of languages out there that might
fit you much better, like Python or Lua. Try those. You'll be a lot happier".

Hans Bezemer

[Hans Bezemer]

On Friday, July 15, 2022 at 10:22:44 AM UTC+2, dxforth wrote:
> > But they managed to get the 'right' order of arguments in their
> > implementation of printf
> Didn't look that far. I saw it as an attempt to impress C programmers.
> in much the same way as Moore did with his BASIC compiler i.e. 'proof
> of concept' rather than for serious use.

You're right, dxforth. Reversing the order of arguments isn't rocket science -
but it is worth the code. I did it once for CONCAT (which I rarely use - or
may be even never, can't remember).

Like I said, I crafted three printf() variants and one sscanf() just to see what
it would take, but I don't think I'll ever seriously use them. I might do Alberts
variant in certain situations when I'm pressed for time (like work), but that's
about it.

The (4tH) libs I most frequently use tend to be quite small, but extremely
useful. When I start to program these pop up almost right away - which I
find most peculiar. But I don't think C-isms like printf() and scanf(), locals or
ANS-94 style files belong to that category.

FYI, neither is S\" There are better ways to do that.

Hans Bezemer

[Hans Bezemer]

On Thursday, July 14, 2022 at 2:08:34 PM UTC+2, none albert wrote:
> With the plethora of arguments it hardly helps of the arguments
> are in the right order. My solution is superior.

Agreed. BTW, I tend to like your solution. It grows on me. I can even
imagine using it - e.g. for work. It got a "logger" lib and composing those
message can be tedious. I could see myself use this one when I'm pressed
for time! Kudos!

Hans Bezemer

[dxforth]

On 15/07/2022 20:51, Hans Bezemer wrote:
>
> To those people I'd like to say "Forth is not for everyone. It is fine as it is.
> But it may not be for you. There are lots of languages out there that might
> fit you much better, like Python or Lua. Try those. You'll be a lot happier".

So much effort has been expended trying to make Forth 'easy' that I often
wonder whether the folks at https://forth-standard.org/ are engaged in
all that for themselves - or the imagined 'lesser' forth user. If the
latter, it's quite condescending. IMO Forth is for those who already have
computing experience and are looking for something that challenges them.
To this day I don't know whether it's possible to program in the way Moore
suggests - but, boy, am I having fun putting it to the test.

[dxforth]

On 15/07/2022 20:59, Hans Bezemer wrote:
>
> Reversing the order of arguments isn't rocket science -
> but it is worth the code. I did it once for CONCAT (which I rarely use - or
> may be even never, can't remember).

I have LOCALS| as an add-on as there may be times I'll want to try out
code that uses locals. I also supply a Hayes-converter - not because
I consider the form superior but because it could be implemented so
easily. The 'how' impressed me far more than the 'what' it did.

\ Hayes-style locals
\ Adapted from:
\ http://www.complang.tuwien.ac.at/forth/anslocal.fs

[undefined] (local) [if] 1 fload locals [then]
forth definitions system

\ : token bl word count ;

-? : lp
>in @ swap token 2dup s" --" compare if
2dup s" }" compare over 0> and if
s" |" compare 0= or
dup if postpone false then
recurse swap >in ! token (local)
end
else
[char] } parse 2drop
then 2drop 2drop >in @ ;

: { false lp >in ! 0 0 (local) ; immediate

application behead lp lp

[Hans Bezemer]

On Saturday, July 16, 2022 at 8:54:55 AM UTC+2, dxforth wrote:
> I have LOCALS| as an add-on as there may be times I'll want to try out
> code that uses locals. I also supply a Hayes-converter - not because
> I consider the form superior but because it could be implemented so
> easily. The 'how' impressed me far more than the 'what' it did.

I got locals as well - but in a quite different form. And yes, it is documented
as well. I cannot implement the "Hayes" variant without embedding it in the
4tH kernel - and it's not worth it IMHO.

Yes, I've used locals when porting some stuff and it works quite reliably. But
it represents a style I do not want to adopt. I'd rather return to C before doing
that.

When I designed 4tH it was primarily because I wanted to make a language
that could be embedded into another program. Yeah, as a matter of fact, it's
basically a "side project" that completely got out of hand.

A language needs programs, though. So I started to make a few examples. I
was convinced the language needed an editor - because all languages I had
known so far always came with an editor.

And before I knew it, I did most development in 4tH - only getting back to C
when enhancing the compiler. Then I found out that for some strange reasons
(which I still haven't completely figured out yet) I could do MUCH more complex
programs faster in 4tH than I ever could in C.

E.g. the preprocessor came out of a CASE..ENDCASE converter - I just had that
one lying around and it seemed a good base to build upon. Now it has a
functionality that challenges M4 - and I'm not quite sure how for Petes sake I
got there. I wouldn't even dream to convert it to C. I wouldn't know where to begin.

And that goes for lots of programs. I use 4tH for work as well - you know, these
simple tools dedicated to do one single nagging task. I've often produced solid
working code in time frames I wouldn't imagine to be achievable with C.
With stack stuff and all.

That's my fascination with this language.

Hans Bezemer

[dxforth]

It appears you're entirely comfortable with the forth you've got.
If that's not the goal of Forth, what is?