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 :(
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 :(
On Friday, July 8, 2022 at 9:55:25 AM 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 don't have S\" but something like it. I built the new string
piecemeal in a different buffer but no longer recall why :(
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).
...
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.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 shebangWell, 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 have S\" but something like it. I built the new string
piecemeal in a different buffer but no longer recall why :(
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 :(
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 stringI typically build strings using MPAD, a string ring buffer, and
piecemeal in a different buffer but no longer recall why :(
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.
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
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 shebangWell, 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..
...
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,
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.
On 9/07/2022 00:42, Hans Bezemer wrote:
But stuff like "\t\tstuff\n"? Not really..
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.
dxforth <dxforth@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.?
On 9/07/2022 19:28, Anton Ertl wrote:
dxforth <dxforth@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.
dxforth <dxforth@gmail.com> writes:
On 9/07/2022 19:28, Anton Ertl wrote:
dxforth <dxforth@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\"?
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".
On 10/07/2022 00:10, Anton Ertl wrote:
dxforth <dxforth@gmail.com> writes:
On 9/07/2022 19:28, Anton Ertl wrote:
dxforth <dxforth@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?
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.
dxforth <dxforth@gmail.com> writes:
On 10/07/2022 00:10, Anton Ertl wrote:
dxforth <dxforth@gmail.com> writes:
On 9/07/2022 19:28, Anton Ertl wrote:
dxforth <dxforth@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.
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> containsIt would have been closer to the truth. Had someone come along and
a problem description. This problem description does not include
anything like "cut C-escapes and paste them into Forth".
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.
I don't have S\" but something like it. I built the new string
piecemeal in a different buffer but no longer recall why :(
dxforth schrieb am Sonntag, 10. Juli 2022 um 05:16:57 UTC+2:
On 10/07/2022 00:10, Anton Ertl wrote:
dxforth <dxf...@gmail.com> writes:'Render obsolete' would be closer to the mark.
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.
S\" wasn't introduced to support the C ecosystem?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\"?
It would have been closer to the truth. Had someone come along andCertainly
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".
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.
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.
<SNIP>dxforth schrieb am Sonntag, 10. Juli 2022 um 05:16:57 UTC+2:
On 10/07/2022 00:10, Anton Ertl wrote:
The proposal <http://www.forth200x.org/escaped-strings.html> containsIt would have been closer to the truth. Had someone come along and
a problem description. This problem description does not include
anything like "cut C-escapes and paste them into Forth".
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.
In article <tag7n0$10ia$1@gioia.aioe.org>, dxforth <dxforth@gmail.com> wrote:
On 11/07/2022 03:45, minf...@arcor.de wrote:<SNIP>
dxforth schrieb am Sonntag, 10. Juli 2022 um 05:16:57 UTC+2:
On 10/07/2022 00:10, Anton Ertl wrote:
The proposal <http://www.forth200x.org/escaped-strings.html> contains >>>> > a problem description. This problem description does not includeIt would have been closer to the truth. Had someone come along and
anything like "cut C-escapes and paste them into Forth".
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.
In article <tag7n0$10ia$1@gioia.aioe.org>, dxforth <dxforth@gmail.com> wrote:
On 11/07/2022 03:45, minf...@arcor.de wrote:<SNIP>
dxforth schrieb am Sonntag, 10. Juli 2022 um 05:16:57 UTC+2:
On 10/07/2022 00:10, Anton Ertl wrote:
The proposal <http://www.forth200x.org/escaped-strings.html> contains >>>>> > a problem description. This problem description does not includeIt would have been closer to the truth. Had someone come along and
anything like "cut C-escapes and paste them into Forth".
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.
That would be SUBSTITUTE REPLACES from 200x that requires the forth
compiler to work? It didn't suit my needs.
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:
dxforth <dxf...@gmail.com> writes:'Render obsolete' would be closer to the mark.
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.
S\" wasn't introduced to support the C ecosystem?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\"?
It would have been closer to the truth. Had someone come along andCertainly
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".
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.
Nonsense, more likely practicality. Worship in Forth is the word forIf you mean "quick and dirty (and lazy) programming" I completely agree
acolytes of Charles Moore.
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 beenS\" 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.Since you provide absolutely zero arguments why this would be true, I tend
I don't think this is wrong. C-isms have been steadily been creeping into Forth - andDenials are to be expected given the contradiction Forth was supposed to beMore nonsense.
the superior language but is now lacking any principle or imagination.
In article <tagqp1$7at$1@gioia.aioe.org>, dxforth <dxforth@gmail.com> wrote:
On 11/07/2022 18:32, albert wrote:
In article <tag7n0$10ia$1@gioia.aioe.org>, dxforth <dxforth@gmail.com> wrote:
On 11/07/2022 03:45, minf...@arcor.de wrote:<SNIP>
dxforth schrieb am Sonntag, 10. Juli 2022 um 05:16:57 UTC+2:
On 10/07/2022 00:10, Anton Ertl wrote:
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.
That would be SUBSTITUTE REPLACES from 200x that requires the forth >>compiler to work? It didn't suit my needs.
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.
On 11/07/2022 05:08, dxforth 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:
dxforth <dxf...@gmail.com> writes:'Render obsolete' would be closer to the mark.
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.
S\" wasn't introduced to support the C ecosystem?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\"?
It would have been closer to the truth. Had someone come along andCertainly
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".
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.
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.
The simple fact that we, as a community, have been unable to come up with any Forth-like alternative is somewhat worrying.
On 12/07/2022 02:20, Hans Bezemer wrote: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.
The simple fact that we, as a community, have been unable to come up with anyEver since ANS nobody has been willing to contradict it. One could say
Forth-like alternative is somewhat worrying.
ANS got its wish. Moore said all innovation would be quashed. It's been replaced with authorized hand-me-downs.
On Tuesday, July 12, 2022 at 6:14:51 AM UTC+2, dxforth wrote:
On 12/07/2022 02:20, Hans Bezemer wrote:
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.The simple fact that we, as a community, have been unable to come up with anyEver since ANS nobody has been willing to contradict it. One could say
Forth-like alternative is somewhat worrying.
ANS got its wish. Moore said all innovation would be quashed. It's been replaced with authorized hand-me-downs.
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: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.
Ever since ANS nobody has been willing to contradict it. One could say
The simple fact that we, as a community, have been unable to come up with any
Forth-like alternative is somewhat worrying.
ANS got its wish. Moore said all innovation would be quashed. It's been
replaced with authorized hand-me-downs.
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.
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: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.
Ever since ANS nobody has been willing to contradict it. One could say
The simple fact that we, as a community, have been unable to come up with any
Forth-like alternative is somewhat worrying.
ANS got its wish. Moore said all innovation would be quashed. It's been
replaced with authorized hand-me-downs.
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.
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 forIf you mean "quick and dirty (and lazy) programming"
acolytes of Charles Moore.
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.
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 stuffS\" 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.
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".
I don't think this is wrong. C-isms have been steadily been creeping into Forth - andDenials are to be expected given the contradiction Forth was supposed to beMore nonsense.
the superior language but is now lacking any principle or imagination.
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.
The standard "\z" conflicts with my z-codes; it will have to change.
To remain fair: the 200x group invites any person to participate and to push forwardIn Holland we had a "referendum law". Anyone could put forward their proposal. In end
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."Paranoid" means fear that people are out to get you specifically. I've learned two
Without wishing to be rude, just honest, that's what I thought aboutIt's always nice to see people starting their rebuttal with a well-meant compliment..
your implementation of REPLACE-ALL a few weeks ago.
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 aNo, 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
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.
Ok, we're getting in ontology territory here. You wanted it, here we go:I tend to regard it as self-evident.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".
Well locals and the file wordset are not just C-isms, I would guess thatFind a language that cannot be traced back to Algol in some way. Forth is
most languages have locals and similar file operations and so, at least
for the latter, familiarity still applies.
Now before you blow a gasketWhat 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.
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.Flattery will get you nowhere ;-)
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.The simple fact that we, as a community, have been unable to come up with anyWell have you tried or taken part in RfD discussions to disagree or
Forth-like alternative is somewhat worrying.
propose alternatives.
what other C-isms in the standard? Off the top of my head, I can onlyIt'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
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.
Do you distinguish between a library and a tool? I regard a regex orYou ask me to distinguish between a tool and a library and then go on to
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 meanBetter ways: "A style of programming that is better suited to align with
different things.
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 onlyIt's C. It's irrelevant whether it is easy to write or not - it's not Forth. My
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.
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.
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.
So yes, regex, printf - all libraries. But very unForth-like libraries. And that
brings us back to square one.
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
In article <ff629506-901f-4e5e-a504-97489a9c56a8n@googlegroups.com>,
Hans Bezemer <the.beez.speaks@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 onlyIt's C. It's irrelevant whether it is easy to write or not - it's not Forth. My
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.
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.
Regards printf, see the one screen I published that covers 90I took me a while to figure out your "special words", but I've managed to craft a 4tH version.
(or 99) of the functionality of c string formatting.
Maybe enhanced with >FLOAT.
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?
On Wednesday, July 13, 2022 at 11:10:02 AM UTC+2, none albert wrote:Some nice statistics on our printf() implementations:
On Tuesday, July 12, 2022 at 10:08:36 PM UTC-5, dxforth wrote:
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?
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.)
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. ;-)
\ 23 4 s" Hello" char !( -- n1 n2 caddr u ch )
\ s" This is %%char%c%%, string %6s and number%*d" printf crch caddr u n2 n1
---8<---
Still - whatever you throw at it, however small - it doesn't feel like Forth,
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 crch 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
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 crch 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? :)
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 crch 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
----
Gerry
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 crch 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? :)
---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
In article <taou9b$2mrf8$1@dont-email.me>,
Gerry Jackson <do-not-use@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 crch 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.
Yeah, <# #S SIGN #> is "the right order".Forth Inc has never used anything but ANS locals.But they managed to get the 'right' order of arguments in their implementation of printf
On Thursday, July 14, 2022 at 1:22:21 PM UTC+2, Gerry Jackson wrote:
Yeah, <# #S SIGN #> is "the right order".Forth Inc has never used anything but ANS locals.But they managed to get the 'right' order of arguments in their
implementation of printf
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.
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 crch 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
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.
But they managed to get the 'right' order of arguments in their implementation of printfDidn'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.
With the plethora of arguments it hardly helps of the argumentsAgreed. BTW, I tend to like your solution. It grows on me. I can even
are in the right order. My solution is superior.
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".
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 outI 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
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.
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 outI got locals as well - but in a quite different form. And yes, it is documented
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.
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 475 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 18:19:35 |
| Calls: | 9,487 |
| Calls today: | 6 |
| Files: | 13,617 |
| Messages: | 6,121,091 |