Win Bigly with Forth-200x!

[hughag...@gmail.com]

On Monday, January 1, 2018 at 8:31:29 AM UTC-7, Howerd wrote:
> Trolls seems to be an unavoidable part of any unmoderated online discussion.
> Scott Adams, of Dilbert fame, called his latest book "Win Bigly - Persuasion in a world where facts don't matter" - and this prompted me to make my New Years resolution : to prefer to live in a world where facts *do* matter.
>
> To this end, I declare an amnesty with the well known comp.lang.fort (clf) trolls, and to strongly recommend that all clf readers check their facts before believing some of the bollocks that people post here.
>
> I don't have a monopoly on the Truth, but there are some easy clues to watch for to weed out the most obvious purveyors of "alternative facts" :
> ...
> 2. People who make personal attacks on individuals.
> ...
> So, dear Reader, "caveat emptor", check the facts and all will be well.
> ...
> Thanks again for reminding me that facts *do* matter, and Happy New Year :-)
>
> Best regards
> Howerd

Facts matter! They do, they do! So, lets check the "facts" that Stephen Pelc gives us.
He is the Forth-200x chair-person, so if he is a liar, then this discredits Forth-200x completely. Here is what Stephen Pelc says:

On Tuesday, August 1, 2017 at 2:27:41 AM UTC-7, Stephen Pelc wrote:
> On Tue, 18 Jul 2017 21:28:18 -0700 (PDT), hughag...@gmail.com
> wrote:
>
> >My complaint against Stephen Pelc is that he uses dishonest business practi=
> >ces. He supports ANS-Forth and Forth-200x for the purpose of making all For=
> >th programmers look stupid. He doesn't actually use ANS-Forth himself. He r=
> >outinely provides vendor-specific code in VFX, even when it is easy to writ=
> >e the code in ANS-Forth, for the purpose of trapping his customers in vendo=
> >r lock-in. A good example is SYNONYM --- I can write this in ANS-Forth usin=
> >g my disambiguifiers --- he insists that this is impossible to write in ANS=
> >-Forth --- he refuses to admit that the disambiguifiers exist because he wa=
> >nts ANS-Forth's FIND to behave differently in every ANS-Forth compiler.
>
> Hugh's wonderful disambiguifiers do NOT do what the great Hugh thinks
> they do. What the great Hugh has done is to redefine a large number of
> words so that they behave in a very restricted way to support the
> great Hugh's version of Forth. Hugh's SYNONYM is not portable ANS
> Forth unless you use Hugh's Forth. Bah, humbug. Another emperor
> with no clothes.
>
> Stephen

First of all, FIND is ambiguous in ANS-Forth.
According to the ANS-Forth document in the entry for IF (section 6.1.1700): "Interpretation semantics for this word are undefined."
The ANS-Forth document has a section (4.1.2) with the ominous heading: "Ambiguous Conditions. One of the many ambiguous conditions is:
"attempting to obtain the execution token, (e.g., with 6.1.0070 ', 6.1.1550 FIND, etc.) of a definition with undefined interpretation semantics."
There are 51 words in the ANS-Forth standard, including IF etc., whose definition includes the statement:
"Interpretation semantics for this word are undefined."
Attempting to obtain the xt of any of these words, using FIND or tick etc., results in an "ambiguous condition." So, FIND is ambiguous for all of these.

Also, we need to look at the definition of FIND (6.1.1550 and 16.6.1.1550):
"For a given string, the values returned by FIND while compiling may differ from those returned while not compiling."
This is ambiguous. The values may differ, or they may not differ. If they do differ, how do they differ? Are they xts from different word-lists? WTF???
In my experience, this ambiguity only occurs for IF etc. (the 51 words mentioned above), although this isn't guaranteed to be true --- it could be any word.
I actually know how this came about. Elizabeth Rather was attempting to appease Charles Moore by making his cmForth be ANS-Forth compliant.
She had heard that FIND in cmForth returned different values inside a colon definition than outside, so she put in this weird rule to make this legal.
Appeasing Charles Moore didn't work --- he continued to consider ANS-Forth to be worthless, and not Forth at all --- he abandoned ANS-Forth in 1989.
I haven't examined cmForth, but most likely colon switches the CONTEXT vocabulary and then semicolon switches it back again.
This would be an obvious explanation. My own MFX cross-compiler switched CONTEXT like this. Making FIND ambiguous is not necessary to support this.

Also, we need to ask what flag (indicating if the word is immediate or not) that FIND returns for a given word. Is this consistent?
No, it is not consistent! It is ambiguous!
In some ANS-Forth systems, words like IF etc. (the 51 words mentioned above) are immediate and in some ANS-Forth systems they are non-immediate.
In Forth-83 these were all immediate, so that would be "common practice," but ANS-Forth does not support common-practice (or common-sense either).

For a long time I believed that the above problems with FIND made ANS-Forth unusable. Then I remembered the disambiguifiers that Anton Ertl invented:

: if state @ 0= if cr ." WARNING: *** no interpretation semantics for: IF ***" cr then
postpone if ; immediate

This fixes all of the problems with FIND listed above! The disambiguifiers are the heart and soul of ANS-Forth programming!

Section 4.1.2 said that an ambiguous condition is:
"attempting to obtain the execution token, (e.g., with 6.1.0070 ', 6.1.1550 FIND, etc.) of a definition with undefined interpretation semantics."
We are no longer attempting this however, because now we are using FIND to obtain the xt of a user-written word (the disambiguifier).

The definition of FIND (6.1.1550 and 16.6.1.1550) said:
"For a given string, the values returned by FIND while compiling may differ from those returned while not compiling."
This isn't guaranteed to be fixed, but in my experience this was only a problem for the 51 problematic words, and was only a problem in Gforth.
This seems to be fixed as a practical matter.

The definition of IF etc. (the 51 problematic words) was ambiguous because it didn't indicate if the word was immediate or non-immediate.
This is fixed because the word is now immediate in all ANS-Forth systems (previously it was non-immediate in VFX and immediate in SwiftForth, etc.).
Making these immediate is what we want, because this was common practice in Forth-83, Forth-79, FIG-Forth, etc..

So, the disambiguifiers fix all the problems FIND introduced by ANS-Forth! Anton Ertl deserves a medal for inventing the disambiguifiers!
What actually happened is that Anton Ertl lost his job as chair-person of the Forth-200x committee and Stephen Pelc was promoted into this exulted position.
Stephen Pelc says:
"Hugh's wonderful disambiguifiers do NOT do what the great Hugh thinks they do."

"What the great Hugh has done is to redefine a large number of words so that they behave in a very restricted way to support
the great Hugh's version of Forth."
Stephen Pelc is a liar --- there are no restrictions --- also, there is no "Hugh's Forth" (this works under VFX, SwiftForth, or any ANS-Forth system).
Stephen Pelc says:
"Hugh's SYNONYM is not portable ANS Forth unless you use Hugh's Forth."
Stephen Pelc is a liar --- SYNONYM is trivial to write so long as FIND works correctly.
The disambiguifiers work in all ANS-Forth systems, therefore my SYNONYM works in all ANS-Forth systems given that the disambiguifiers are already included.
Stephen Pelc says:

All of this started way back in 2009 when I wrote an early-binding MACRO: and thought it worked (I tested it under SwiftForth and it did work).
It didn't work under gForth however, because it needed to ['] semicolon which is one of the 51 problematic words, and gForth crashed.
Anton Ertl pointed out that crashing is legal in ANS-Forth because ticking semicolon is an ambiguous condition, so anything is legal.
It was in this thread that Anton Ertl invented the disambiguifiers as a solution, although I didn't grok this solution for several years:
https://groups.google.com/forum/#!topic/comp.lang.forth/wP5nw1ClzsM%5B1-25%5D
After I put the disambiguifiers in the novice-package, I was able to write my early-binding MACRO: and it worked because FIND worked. This was trivial!

I said at the top of this post:
"Stephen Pelc is the Forth-200x chair-person, so if he is a liar, then this discredits Forth-200x completely."
I have now shown that Stephen Pelc is a blatant liar --- so, Forth-200x is completely discredited --- as Howerd said: facts matter!

Happy New Year!

[dxf...@gmail.com]

"Win Bigly with Forth-200x!"

Fact or promotional material?

[gavino himself]

too long
can you give us the cliffs?
huge hows the forth for web sites working lately?
werc.cat-v.org what think?

[hughag...@gmail.com]

On Monday, January 1, 2018 at 5:24:35 PM UTC-7, hughag...@gmail.com wrote:
> For a long time I believed that the above problems with FIND made ANS-Forth unusable. Then I remembered the disambiguifiers that Anton Ertl invented:
>
> : if state @ 0= if cr ." WARNING: *** no interpretation semantics for: IF ***" cr then
> postpone if ; immediate
>
> This fixes all of the problems with FIND listed above! The disambiguifiers are the heart and soul of ANS-Forth programming!

Anton Ertl invented disambiguifiers in 2009 in this thread:

https://groups.google.com/forum/#!topic/comp.lang.forth/wP5nw1ClzsM%5B1-25%5D

Note that in this thread Anton Ertl is criticizing me for expecting FIND and tick to behave the same way in every ANS-Forth system.
He is telling me that FIND and tick have multiple incompatible behaviors, all of which are allowed by ANS-Forth.
He is criticizing me for failing to anticipate that my early-binding MACRO: that ran under SwiftForth would crash under gForth.

On Thursday, November 26, 2009 at 3:24:06 AM UTC-7, Anton Ertl wrote:
> Hugh Aguilar <hugoa...@rosycrew.com> writes:
> IF and ";" are not immediate words in the standard. A system can
> implement them as immediate words, but a program cannot rely on their
> immediacy.
>
> >I looked up ['] in the ANS-Forth document and it says:
> >
> >"Place name's execution token xt on the stack."
>
> What's the execution token of a word that has no execution semantics?
>
> Hmm, since you think that ";" is immediate, I guess you want an
> execution token that, when executed, performs the compilation
> semantics. You can get that as follows. Before the rest of the
> program, define:
>
> : ; postpone ; ; immediate
>
> Now you have an immediate ";" with an execution semantics that's the
> same as the compilation semantics, and you can tick it.
>
> >What I am saying is that I didn't have any warning that what I was
> >doing in MACRO: was going to be a problem.
>
> A system that would tell us all non-standard usages would be nice, but
> we don't have that. For now the solution is to test on as many
> systems as possible.

Now here is Anton Ertl being grossly dishonest in 2018 in this thread:

https://groups.google.com/forum/#!topic/comp.lang.forth/8orqw1vjTOY%5B126-150%5D

On Sunday, August 12, 2018 at 10:21:25 AM UTC-7, Anton Ertl wrote:
> The point of a standard is that we can run programs on multiple
> systems. E.g., even though I consider FIND outdated, I occasionally
> use it when I want to write a portable program.

What has happened between 2009 and 2018 that has caused Anton Ertl to go from inventing the disambiguifiers to saying that FIND is not ambiguous?
Well, Anton Ertl was chair-person of the Forth-200x committee in 2009 and he was more willing to speak truthfully then.
Now Anton Ertl has been demoted to lowly committee member and Stephen Pelc is the new chair-person ---
Anton Ertl now is obliged to parrot Stephen Pelc --- of course, Stephen Pelc says that FIND is not ambiguous --- so Anton Ertl parrots him.

I think that Elizabeth Rather demoted Anton Ertl as punishment for inventing the disambiguifiers ---
she really expects the Forth-200x chair-person to be a liar and say that ANS-Forth is not ambiguous.
Anybody who is unwilling to lie for her will be demoted --- the next step down for Anton Ertl will be to become a Forth-200x mailing-list sycophant!

[hughag...@gmail.com]

Here we have Anton Ertl promoting disambiguifiers again:

On Saturday, August 18, 2018 at 11:33:51 AM UTC-7, hughag...@gmail.com wrote:
> On Saturday, August 18, 2018 at 1:09:19 AM UTC-7, Anton Ertl wrote:
> > Ruvim <ruvim...@gmail.com> writes:
> > >NB: to make "postpone ;]" work inside postpone{} the 'postpone' word
> > >should be too clever. So the workaround "';] execute" is used to remove
> > >the effect of immediacy (if any). In absence of such clever tick
> > >recognizer we can just define a constant:
> > > ' ;] constant ';]
> > >Or an alias that represents execution semantics only:
> > >: regular-;] postpone ;] ;
> >
> > Ticking ;] will be non-standard, because the interpretation semantics
> > of ;] is undefined in the proposal. The way to go is to have a normal
> > word that performs the compilation semantics at its run-time (like
> > your REGULAR-;], although the name is perverse), and then directly use
> > it inside ]] ... [[ (or with your bike shed colour of that, or to just
> > POSTPONE it).
>
> This "alias" is a disambiguifier. It should be immediate though:
>
> : regular-;] postpone ;] ; immediate
>
> Also, what is the point of the "perverse" name? Why not just do this?
>
> : ;] postpone ;] ; immediate

This is actually in a Forth-200x RfD discussion --- so apparently Forth-200x has the same problem with FIND being ambiguous as ANS-Forth does.

Anton Ertl is recommending using this disambiguifier inside of ]] ... [[ constructs.
The ]] ... [[ construct is Forth-200x. I don't need this because I have my early-binding MACRO: definer written in ANS-Forth.
Note that the early-binding MACRO: depends upon having disambiguifiers loaded for all the words like IF etc. in ANS-Forth that screw up FIND .
The ]] ... [[ construct is also going to need all of these words disambiguified if it is going to work --- anybody who says that it works but also says
that disambiguifiers are not necessary is a liar.

Disambiguifiers will utterly destroy the credibility of the ANS-Forth cult --- this is because they become blatant liars ---
they can't admit that FIND in ANS-Forth is ambiguous because doing so requires them to admit that Elizabeth Rather is an idiot.
Refusing to admit a mistake, even after a solution to the mistake has been provided, is the hallmark of a cult.

BTW: The ]] ... [[ construct is absurdly ugly because the brackets point in the wrong direction! Who thinks this stuff up???
It must have been the same person who thought up the idea of making the LOCALS| parameters backwards.
It was Anton Ertl who changed the name of { to {: and also failed to define the parameters to the right of the | as being initialized to zero.
He seems like the most likely candidate for getting the ]] [[ brackets backwards.
I do actually understand the logic behind making them backwards, but this is just ugly and weird --- brackets always point inward, not outward!

[hughag...@gmail.com]

On Saturday, September 8, 2018 at 8:06:13 PM UTC-7, hughag...@gmail.com wrote:
> Disambiguifiers will utterly destroy the credibility of the ANS-Forth cult --- this is because they become blatant liars ---
> they can't admit that FIND in ANS-Forth is ambiguous because doing so requires them to admit that Elizabeth Rather is an idiot.
> Refusing to admit a mistake, even after a solution to the mistake has been provided, is the hallmark of a cult.

Well, I have searched through comp.lang.forth looking for anybody who publicly agrees with Stephen Pelc regarding the disambiguifiers.
So far, I have only found Rickman to do so.
Everybody else dodges the issue. They don't want to publicly agree with Stephen Pelc because they know that Stephen Pelc is lying.
They don't want to publicly state that Stephen Pelc is lying though, because then Stephen Pelc will kick them off the Forth-200x mailing-list,
and they won't get to be internet-experts anymore --- so they just tacitly support Stephen Pelc's lies, without fully committing themselves.

Here is brave Rickman fully committing himself to supporting Stephen Pelc's lies:

On Sunday, August 6, 2017 at 8:08:23 PM UTC-7, hughag...@gmail.com wrote:
> On Tuesday, August 1, 2017 at 2:27:41 AM UTC-7, Stephen Pelc wrote:
> > On Tue, 18 Jul 2017 21:28:18 -0700 (PDT), hughag...@gmail.com
> > wrote:
> >
> > >My complaint against Stephen Pelc is that he uses dishonest business practi=
> > >ces. He supports ANS-Forth and Forth-200x for the purpose of making all For=
> > >th programmers look stupid. He doesn't actually use ANS-Forth himself. He r=
> > >outinely provides vendor-specific code in VFX, even when it is easy to writ=
> > >e the code in ANS-Forth, for the purpose of trapping his customers in vendo=
> > >r lock-in. A good example is SYNONYM --- I can write this in ANS-Forth usin=
> > >g my disambiguifiers --- he insists that this is impossible to write in ANS=
> > >-Forth --- he refuses to admit that the disambiguifiers exist because he wa=
> > >nts ANS-Forth's FIND to behave differently in every ANS-Forth compiler.
> >
> > Hugh's wonderful disambiguifiers do NOT do what the great Hugh thinks
> > they do. What the great Hugh has done is to redefine a large number of
> > words so that they behave in a very restricted way to support the
> > great Hugh's version of Forth. Hugh's SYNONYM is not portable ANS
> > Forth unless you use Hugh's Forth. Bah, humbug. Another emperor
> > with no clothes.
> >
> > Stephen
>

> Stephen Pelc is another liar.

On Monday, August 7, 2017 at 1:06:49 AM UTC-7, rickman wrote:
> hughag...@gmail.com wrote on 8/6/2017 11:08 PM:
> >
> > Stephen Pelc is another liar.
>
> So to address Gerry and other's concerns that Hugh's insane comments that
> appear to impune others, this is a perfect example. First Hugh responds to
> Stephen (not Steven) on the subject matter of disambiguafiers. Then he
> posts this simple, yet absurd statement.
>
> No one with a lick of sense would give Hugh any credibility. There is no
> need to Hugh or involve him in a discussion of his delusions.
>
> Just get over him and ignore him instead of letting him involve you in his
> fantasies.
>
> --
>
> Rick C

[hughag...@gmail.com]

On Saturday, September 8, 2018 at 8:06:13 PM UTC-7, hughag...@gmail.com wrote:

As I said above: MACRO: can't be written without the disambiguifiers because it depends upon FIND working for IF etc., which is ambiguous in ANS-Forth.
Also, Forth-200x appears to have the same problem with FIND that ANS-Forth does, as Anton Ertl said that an "alias" (disambiguifier) is needed.

Here is another interesting quote:

On Saturday, September 15, 2018 at 10:16:38 PM UTC-7, hughag...@gmail.com wrote:
> On Friday, September 14, 2018 at 7:39:35 PM UTC-7, hughag...@gmail.com wrote:
> > On Thursday, September 13, 2018 at 1:58:32 PM UTC-7, Alex McDonald wrote:
> > > The
> > > recognizer proposal gets rid of immediacy entirely;
> >
> > Forth-200x does not deserve to be called "Forth" --- it definitely doesn't deserve to be called the "Forth Standard."
> >
> > Immediacy is actually a fundamental part of Forth.
>
> Most likely, the reason why Stephen Pelc supports the recognizer RfD, and the abandonment of immediacy, is because he wants to prevent
> cross-compilers from being written in Forth-200x in competition with MPE that makes most of its money from cross-compilers.
>
> Obviously, immediacy is needed for a cross-compiler.

Obviously, immediacy is also needed for MACRO: --- all of those macros are immediate.
Alex McDonald says: "The recognizer proposal gets rid of immediacy entirely;"
The recognizers aren't capable of being the basis for anything like MACRO: that generates immediate meta-compiling words.
Emperor Pelc has given the recognizer RfD 100% support, and he is the Forth-200x chairman, so it is only a matter of time before recognizers are accepted.

All in all, I think that Stephen Pelc is purposely crippling Forth-200x to prevent users from implementing useful features with standard Forth.
The purpose of this, is so Stephen Pelc can introduce these useful features into VFX as proprietary closed-source features.
This makes Stephen Pelc look like a genius, as he has implemented features that common Forthers are unable to implement. VFX looks relatively good ($$$).

We already have Factor that lacks immediacy. I pointed out that this prevents Factor from being capable of supporting a Forth cross-compiler.
Slava Pestov told me that this was true, but he didn't care --- he has no interest in supporting Forth cross-compilers ---
he is interested in supporting desktop-computer software.
He is competing against Python and Ruby in convenience, and his selling point is execution speed. Meta-compiling (immediate words) is not part of this plan.

If Stephen Pelc continues to cripple Forth-200x, and he adds useful features to VFX that can't be written in Forth-200x, the result will be
that VFX competes against Factor, Python, Ruby, etc.. This isn't going to work well for Pelc because VFX costs a lot of money and those languages are free.
Also, those languages (especially Python) already have beaucoup code-libraries available, and VFX doesn't have any code-libraries available.
Factor offers the fastest execution speed of all these languages, afaik. VFX may or may not be able to beat Factor in regard to execution speed.
Execution speed is largely irrelevant in the desktop-computer market though, as the 64-bit x86 is orders of magnitude faster than necessary for most programs
(Python became the leader despite having abysmal execution-speed; now there are somewhat faster versions, but it still lacks the speed of C, C++ etc.).

Stephen Pelc is crippling Forth-200x, and harming the entire Forth community.
This is just a gamble on his part that VFX can take over the desktop-computer programming field and he can become rich (he charges hundreds of dollars!).
His gamble has little or no chance of success --- he will fail! --- he will first drag the entire Forth community down into failure!
This is like going all-in on pocket deuces, after the flop has brought all high cards, in the hope of him getting rich by rivering a deuce.
He is betting the Forth community's credibility which doesn't belong to him --- it is not his right to cripple the Forth standard just to make VFX look good.

[hughag...@gmail.com]

Here is another interesting quote:

On Thursday, April 2, 2015 at 10:07:52 AM UTC-7, Stephen Pelc wrote:
> On Wed, 1 Apr 2015 13:40:52 -0700 (PDT), hughag...@gmail.com
> wrote:
> >So how do you write SYNONYM so that it can make a synonym of an immediate word?
>
> The VFX source code is:
>
> : SynComp, \ xt --
> \ Compile a child of SYNONYM.
> >body @ compile,
> ;
>
> : Synonym \ "<new-name>" "<curdef>" --
> \ *G Create a new definition which redirects to an existing one.
> \ ** Normal dictionary searches for *\i{<new-name>} will return
> \ ** the xt of *\i{<curdef>}.
> create
> hide ' reveal dup , immediate?
> if immediate endif
> ['] SynComp, set-compiler
> $010 latest set-bit \ set header's alias bit
> interp>
> @ execute
> ;
>
> For some words you may have to RTFM.
>
> Stephen

Cynical readers will notice that this code is not ANS-Forth. When Stephen Pelc (Forth-200x committee member) tells the plebian (Hugh Aguilar) to RTFM (Read The F'ing Manual), he is referring to the VFX manual. All of that code is VFX-specific. Stephen Pelc is trying to trap the VFX users into relying on vendor-specific code so they won't be able to port their code to competitor's ANS-Forth compilers --- vendor lock-in, of course, is what the standard is supposed to prevent!

Alert readers will also notice this code has a bug in it. If SYNONYM is used to make a synonym of a word defined with CREATE and then >BODY is used on the synonym, >BODY will not return the body-address of the original word. I have read on comp.lang.forth that VFX has a new version that fixes this bug. I haven't bothered to download the new version however, so I haven't verified this. The more important problem is that Stephen Pelc is refusing to acknowledge the existence of the disambiguifiers and he is insisting that a word such as SYNONYM "requires carnal knowledge."

On Thursday, April 2, 2015 at 11:42:55 PM UTC-7, Stephen Pelc wrote:
> On Thu, 2 Apr 2015 19:18:04 -0700 (PDT), hughag...@gmail.com
> wrote:
> >This is not ANS-Forth code --- I don't want to RTFM because I don't want to
> > become an expert on VFX --- I'm already an expert on ANS-Forth.
>
> You asked a tech-support question about VFX. I answered it pointing
> out that your initial assumption (how IF works) was wrong.
>
> The code illustrates precisely why SYNONYM is defined the way it is
> defined - because it requires carnal knowledge. If you want to know
> how SYNONYM works:
> "So how do you write SYNONYM so that it can make a synonym of an
> immediate word?"
> then do not complain when you are told.
>
> Stephen

My assumption about IF was that it was immediate. This is sometimes right (SwiftForth) and sometimes wrong (VFX). The ambiguity of ANS-Forth, however, is meta-wrong --- ambiguity such as this is absurd --- ANS-Forth is a standard that doesn't standardize.

Stephen Pelc is an extremely arrogant person! He is trying hard to say that I'm incompetent and that I need to learn basic Forth programming from him.
He is incompetent and should learn from me! He does not deserve to be the Forth-200x chair-person!

Anyway, my SYNONYM SYNONYM-FAST and ALIAS are all ANS-Forth and they all support immediate words. They depend upon the disambiguifiers to work:
-----------------------------------------------------------------------
: oink postpone if ; immediate ok
: test oink ." true" else ." false" then ; ok
1 test true ok
0 test false ok
get-current alias oinkA oink ok
: testA oinkA ." true" else ." false" then ; ok
1 testA true ok
0 testA false ok
get-current synonym oinkS oink ok
: testS oinkS ." true" else ." false" then ; ok
1 testS true ok
0 testS false ok
get-current synonym-fast oinkFS oink ok
: testFS oinkFS ." true" else ." false" then ; ok
1 testFS true ok
0 testFS false ok
-----------------------------------------------------------------------

Also, ALIAS supports >BODY correctly, which Stephen Pelc's non-standard code shown above failed to support:
-----------------------------------------------------------------------
create foo 1234 , ok
get-current alias bar foo ok
foo @ . 1234 ok
bar @ . 1234 ok
' foo >body @ . 1234 ok
' bar >body @ . 1234 ok
foo . 5167168 ok
bar . 5167168 ok
ok
5678 foo ! ok
foo @ . 5678 ok
bar @ . 5678 ok
' foo >body @ . 5678 ok
' bar >body @ . 5678 ok
-----------------------------------------------------------------------

[gnuarm.del...@gmail.com]

Not that I need it, but thank you for justifying my concerns.

BTW, if you were in your right mind you would readily realize nothing I wrote above supported anything Stephen Pelc wrote. I was only commenting on your apparent mental issues.

Rick C.

[hughag...@gmail.com]

First you supported Stephen Pelc by saying that it was "absurd" that I should say that Stephen Pelc is a liar.
Then you punked out and said that nothing you wrote supported anything that Stephen Pelc wrote.
Stephen Pelc is a liar. Rick C is a troll who gets off on flinging insults at me, but is unwilling to stand by what he says.

Here is another example of Anton Ertl contradicting Stephen Pelc, and essentially saying that Stephen Pelc is a liar:

On Wednesday, August 10, 2016 at 7:56:36 PM UTC-7, hughag...@gmail.com wrote:
> On Tuesday, August 9, 2016 at 7:08:55 AM UTC-7, Anton Ertl wrote:
> > hughag...@gmail.com writes:
> > >On Monday, August 8, 2016 at 2:05:38 AM UTC-7, Anton Ertl wrote:
> > >> There is no provision in the standard for FIND giving an error on
> > >> valid input.
> > >
> > >According to the ANS-Forth document in the entry for IF (section 6.1.1700):=
> > > "Interpretation semantics for this word are undefined." The ANS-Forth docu=
> > >ment has a section (4.1.2) with the ominous heading: "Ambiguous Conditions.=
> > >" One of the many ambiguous conditions is: "attempting to obtain the execut=
> > >ion token, (e.g., with 6.1.0070 ', 6.1.1550 FIND, etc.) of a definition wit=
> > >h undefined interpretation semantics."
> >
> > Good catch. Interestingly, the definition of FIND does not mention
> > that, and given the return values that FIND can produce, and the way
> > that FIND is used, I don't think it makes sense.
>
> Well, I'm glad that you are admitting that FIND in ANS-Forth is broken. I would use the term "sabotaged" because there is no point to making FIND not work except to prevent the programmer from writing an outer-interpreter.
>
> It is disingenious to describe this as a "good catch" in the year 2016. You yourself pointed this problem out to me in 2009, and you provided the way to fix it. This was in this thread:
> https://groups.google.com/forum/#!topic/comp.lang.forth/wP5nw1ClzsM%5B1-25%5D
>
> On Thursday, November 26, 2009 at 3:24:06 AM UTC-7, Anton Ertl wrote:
> > Hugh Aguilar <hugoa...@rosycrew.com> writes:
> > >I don't understand how a word can not have execution semantics.
> >
> > That's quite simple: By not defining execution semantics in the
> > definition of the word in the standard document. Look up the
> > definition of ";" in the standard, and you will see that there is no
> > "Execution:" section there; and there are other labeled sections
> > there, so the "omitted label" sentence of 3.4.3.1 does not apply.
> >
> > >For immediate words (IF, ;, etc.)

> >
> > IF and ";" are not immediate words in the standard. A system can
> > implement them as immediate words, but a program cannot rely on their
> > immediacy.
> >
> > >I looked up ['] in the ANS-Forth document and it says:
> > >
> > >"Place name's execution token xt on the stack."
> >

> > What's the execution token of a word that has no execution semantics.

> >
> > Hmm, since you think that ";" is immediate, I guess you want an
> > execution token that, when executed, performs the compilation
> > semantics. You can get that as follows. Before the rest of the
> > program, define:
> >
> > : ; postpone ; ; immediate
> >
> > Now you have an immediate ";" with an execution semantics that's the
> > same as the compilation semantics, and you can tick it.
> >
> > >What I am saying is that I didn't have any warning that what I was
> > >doing in MACRO: was going to be a problem.
> >
> > A system that would tell us all non-standard usages would be nice, but
> > we don't have that. For now the solution is to test on as many
> > systems as possible.
>

> What you have above above are what I now have in the novice-package and call "disambiguifiers." Here is one disambiguifier copied out of the novice-package:
> : if state @ 0= abort" *** no interpretation semantics for: IF ***"
> postpone if ; immediate
>
> This is just a bug-fix for ANS-Forth. Straight Forth doesn't need disambiguifiers because it is just straight Forth without ambiguity.

The bottom line here is that Stephen Pelc was lying when he said that my disambiguifiers don't work.
He needs to just admit that he lied.
This would also be a good time for him to resign from the Forth-200x committee on the grounds that his only goal is to make MPE profitable.
It is impossible to serve both the Forth community, which is in competition with MPE, and to serve MPE which is where he makes his money.

This is why he lied about the disambiguifiers --- he wanted SYNONYM SYNONYM-FAST ALIAS and the early-binding MACRO: to be proprietary to MPE,
all of which rely on the disambiguifiers to be installed in order to work under ANS-Forth, because they all use FIND internally.
He wanted the Forth community to believe that code like this is impossible in ANS-Forth, and they have to pay MPE for it.

This is also why he supported the fake quotations --- he wanted rquotations to be proprietary to MPE.
He wanted the Forth community to be stuck with the useless fake quotations in Forth-200x, and believe that they have to pay MPE for rquotations.

He wants everything useful to be proprietary to MPE --- only available by buying VFX for big $$$ --- he wants the Forth standard to be crippled and useless.
He wants to insult me by saying: "You just have to RTFM the VFX manual if you want to be a Forth programmer, but you aren't a Forth programmer if you don't."

[foxaudio...@gmail.com]

Just because you are not paranoid, doesn't mean they are not out to get you. :-/

[Manuel Rodriguez]

Am Freitag, 2. November 2018 12:41:02 UTC+1 schrieb foxaudio...@gmail.com:
> Just because you are not paranoid, doesn't mean they are not out to get you. :-/

Paranoia is often misinterpreted as a psychological behavior from an
individual. But in reality, paranoia is an element in storytelling about
failed software projects. Let us make an example: The IBM OS/2 project
failed because it wasn't able to replace Windows NT. What does the OS/2
manager felt before he quit? Right, he thought, that he lost the game,
he thought that Microsoft is superior, he thought that everything was
wrong with him and his team. In short, he was paranoid in relationship
to the environment.

Now let us construct a counter example. The project manager of another
has lots of success. Will he feel paranoia? Will he think, that he made
a mistake. Does he feels fear that something bad will happen next day in
his job? No, he is relaxed and looks confident into the future.

[dxf...@gmail.com]

Success is often a precursor to paranoia - fear of losing what one
has gained. Standard Forth doesn't have that problem. Its paranoia
stems from its inability to replace Chuck as Forth's leader. Whereas
Chuck's message is 'Here's what I do' - Standard Forth's is 'Do what
I say' and that's not appealing to most forthers.

[Manuel Rodriguez]

Am Samstag, 3. November 2018 01:35:25 UTC+1 schrieb dxf...@gmail.com:
> Standard Forth doesn't have that problem. Its paranoia
> stems from its inability to replace Chuck as Forth's leader.

You mean, that Chuck Moore plans a conspiracy against Forth-200x? Another
source has the same information. quote: “The ANS Forth standard does not
express Moore's vision of Forth. ” http://wiki.c2.com/?ChuckMoore

But was is the position of GreenArrays? Are they are with Chuck also part
of the anti ANS-Forth conspiracy? This is a bit unclear. According to
http://www.greenarraychips.com/home/about/bios.html two members of
Greenarrays were in the past member of the ANS Forth committee.

[Anton Ertl]

Manuel Rodriguez <a...@gmx.net> writes:
>The IBM OS/2 project
>failed because it wasn't able to replace Windows NT.

The original plan for OS/2 was to replace PC DOS, not Windows NT.
Windows NT was actually originally a from-scratch reimplementation of
OS/2, and it's original name was NT OS/2. It was renamed into Windows
NT after Windows 3 became popular (after the lack of uptake of Windows
1, Windows 2, and OS/2 1.x).

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2018: http://www.euroforth.org/ef18/

[dxf...@gmail.com]

On Saturday, November 3, 2018 at 8:08:19 PM UTC+11, Manuel Rodriguez wrote:
> Am Samstag, 3. November 2018 01:35:25 UTC+1 schrieb dxf...@gmail.com:
> > Standard Forth doesn't have that problem. Its paranoia
> > stems from its inability to replace Chuck as Forth's leader.
>
> You mean, that Chuck Moore plans a conspiracy against Forth-200x?

Now that would be paranoid :)

> Another
> source has the same information. quote: “The ANS Forth standard does not
> express Moore's vision of Forth. ” http://wiki.c2.com/?ChuckMoore

Moore's position on Forth is re-iterated in his EF2018 speech.

"I never wrote Forth for you. I wrote Forth for me."

Forth for Moore has been a journey of discovery. ISTM if one plans
to travel far then one must pack lightly.

>
> But was is the position of GreenArrays? Are they are with Chuck also part
> of the anti ANS-Forth conspiracy? This is a bit unclear. According to
> http://www.greenarraychips.com/home/about/bios.html two members of
> Greenarrays were in the past member of the ANS Forth committee.

The simpler answer is that they've just moved on.

[hughag...@gmail.com]

On Saturday, November 3, 2018 at 6:46:47 PM UTC-7, dxf...@gmail.com wrote:
> On Saturday, November 3, 2018 at 8:08:19 PM UTC+11, Manuel Rodriguez wrote:
> > Am Samstag, 3. November 2018 01:35:25 UTC+1 schrieb dxf...@gmail.com:
> > > Standard Forth doesn't have that problem. Its paranoia
> > > stems from its inability to replace Chuck as Forth's leader.
> >
> > You mean, that Chuck Moore plans a conspiracy against Forth-200x?
>
> Now that would be paranoid :)
>
> > Another
> > source has the same information. quote: “The ANS Forth standard does not
> > express Moore's vision of Forth. ” http://wiki.c2.com/?ChuckMoore
>
> Moore's position on Forth is re-iterated in his EF2018 speech.
>
> "I never wrote Forth for you. I wrote Forth for me."
>
> Forth for Moore has been a journey of discovery. ISTM if one plans
> to travel far then one must pack lightly.

For Charles Moore to plan a conspiracy against ANS-Forth would be like planning a conspiracy against a wart on his face.
It is possible to surgically remove a wart, but there is a possibility to cause infection, so it is generally best to leave the wart despite its ugliness.
The problem with this, is that the wart may multiply.
First there was ANS-Forth that was ugly, and now there is also Forth-200x that is also ugly, but is about 10x bigger. Forth-200x grows bigger every year!

What Forth needs now is a scalpel and a big bottle of hydrogen-peroxide. The scalpel is to remove the ugly warts, which are ANS-Forth and Forth-200x.
The hydrogen-peroxide is to wash away the bacteria that causes these ugly growths.
The bacteria I'm referring to are Anton Ertl and Bernd Paysan. Their fake-quotations and recognizers were not positive contributions to Forth.

> > But was is the position of GreenArrays? Are they are with Chuck also part
> > of the anti ANS-Forth conspiracy? This is a bit unclear. According to
> > http://www.greenarraychips.com/home/about/bios.html two members of
> > Greenarrays were in the past member of the ANS Forth committee.
>
> The simpler answer is that they've just moved on.

Charles Moore abandoned ANS-Forth in 1989, and slammed the door on his way out, but his name was listed on the ANS-Forth document in 1994 as a supporter anyway.
The same thing is true of everybody who contributed to ANS-Forth --- they all abandoned ANS-Forth prior to 1994 --- they were listed as supporters anyway.
Only Stephen Pelc stuck with ANS-Forth --- he embraced the filth --- he didn't move on.

The whole point of the Forth-200x mailing-list is to collect names of Forth programmers so they can be listed on the Forth-200x document as supporters.
Abandoning the Forth-200x mailing-list won't save a person --- his or her name has been captured --- the Forth-200x committee will hang on to it forever.

[Cecil - k5nwa]

The simpler answer is generally the best solution, conspiracy is too
strong a word for something that has a simpler explanation, he is more
interested in his own journey to find his perfect solution based on
simplicity and what feels right. He has never been afraid of breaking
thing to improve them which is the opposite of the thrust of the ANS
committee which is to preserve backward compatibility at the expense of
simplicity and clarity.

--

Cecil - k5nwa

[gnuarm.del...@gmail.com]

Yes, and that is the difference between an organization who's purpose to provide a stable environment which allows commercial enterprise to work with certainty and visibility and individuals who's goals are to optimize their personal experience and facility.

No one is compelled to use any standard other than by the advantages of that standard. If there are not sufficient advantages for a standard to be used by anyone or on any project it won't be used. If the advantages are sufficient then the standard is used.

Seems like a workable arrangement to me.

Rick C.

[hughag...@gmail.com]

On Saturday, November 3, 2018 at 6:46:47 PM UTC-7, dxf...@gmail.com wrote:

> Moore's position on Forth is re-iterated in his EF2018 speech.
>
> "I never wrote Forth for you. I wrote Forth for me."
>
> Forth for Moore has been a journey of discovery. ISTM if one plans
> to travel far then one must pack lightly.

According to Jeff Fox, Charles Moore was not opposed to having a standard. He was opposed to ANS-Forth because ANS-Forth is stupid in every way.
He wanted to have a Forth standard so Forthers could write code that was portable between Forth vendors. That would make Forth commercially useful.

The person who is primarily opposed to having a standard is Stephen Pelc.
He doesn't want code to be portable between Forth vendors --- obviously this implies that there is more than one Forth vendor.
He wants MPE to be the only Forth vendor, so the concept of porting code between Forth vendors would become moot.
This is why he is purposefully crippling Forth-200x with the fake-quotations.

Also, Charles Moore was not such a minimalist as he is represented as being (your "pack lightly" comment above).
He left Forth Inc. in 1982, which was only a few years after inventing Forth (roughly 1977, although he had some proto-Forths as early as 1974 or 1975).
He just didn't have time to add many features to Forth before getting kicked out of Forth Inc. by Elizabeth Rather.

For example, he didn't implement a D/ (double-precision division). Most likely he was primarily using Forth as a micro-controller and didn't need it.
He was most likely using Fortran on a PDP-11 to do numeric programming.
For example, there are Fortran programs to do continued-fractions that provide ratio-approximations that can then be used in the Forth programs.
He may never have gotten as far as expecting Forth to compete with Fortran as a numeric programming language (as Skip Carter envisioned).

The problem is that ANS-Forth set all of this 1970s Forth in stone, so that it can never be changed.

Consider this thread:
https://groups.google.com/forum/#!topic/comp.lang.forth/BcWvGxFFuzA%5B1-25%5D

On Friday, November 20, 2009 at 12:07:12 AM UTC-7, Elizabeth D Rather wrote:
> Hugh Aguilar wrote:
> ...
> > The problem is the ANS-Forth standard. Really, how obvious was the
> > need for double-precision arithmetic? This could have been an
> > extension to the language similar to floating-point. Compiler-writers
> > working on small microprocessors could decline to implement it if they
> > didn't want to.
> >
> > I am frustrated with the ANS-Forth standard because I believe that the
> > bad design of the standard is the #1 reason for the failure of Forth
> > to become an important language. Forth was doing pretty well in the
> > 1980s, but we needed a standard. What we got was Forth-83, and then
> > ANS-Forth-94, both of which were badly designed. With some more
> > thoughtful leadership we could have succeeded.
>
> There are D+, D-, M*, M/, and M*/ (and the unsigned operators). These
> were adequate in a very wide variety of projects over a 30 year period,
> many of which were extremely computation-intensive and running on slow
> 16-bit processors.
>
> Forth's design is pragmatic: it has functions that have been needed and
> that have proven their usefulness *in Forth*, not necessarily those that
> have been required in other languages. Generally speaking, Forth has
> the most flexible set of *integer* arithmetic operators of any language.
> In particular, M*/ was one of Chuck's most brilliant innovations. I'm
> sure if Chuck were trying to do your continued fractions that is what he
> would rely on. Yes, that sometimes requires thinking differently, like
> many other things in Forth.
>
> Cheers,
> Elizabeth

Elizabeth Rather assumes that because Charles Moore didn't write a D/ this implies that D/ has to be banned forever.
------------------
D/ is non-standard! Charles Moore didn't need D/ in the 1970s, so nobody can ever claim that they need it for any purpose. D/ is the devil!
------------------
Also, as a practical matter, none of the "programmers" at Forth Inc. knew how to implement D/ because the division algorithm is too complicated for them.
They are maintenance programmers --- they just maintain PolyForth year after year, decade after decade...

So, the result is that in 2009 Elizabeth Rather tells me that I'm not a Forth programmer at all, because I think D/ is needed for continued-fractions.
Nathaniel Grossman didn't have D/ either, so he wrote his own D/ in high-level Forth to support his continued-fraction program, back in 1984 for FD.
I stuck with this too when I ported his program from Forth-83 to ANS-Forth.
This is very crude though --- D/ should be part of the standard so it can be written in assembly-language --- writing D/ yourself in Forth is bizarre!

Consider this thread:
https://groups.google.com/forum/#!topic/comp.lang.forth/0iBCFp9l9IY%5B1-25%5D

On Tuesday, July 3, 2018 at 2:14:22 AM UTC-7, Albert van der Horst wrote:
> In article <0ff9666d-e22e-4370...@googlegroups.com>,
> <hughag...@gmail.com> wrote:
> >On Monday, July 2, 2018 at 3:54:28 AM UTC-7, Albert van der Horst wrote:
> >>
> >> \ You only need D- and D<=
> >> : .cf2 BEGIN 100000 0 DO 2OVER D- 2DUP 0. D<= IF I . LEAVE THEN
> >> LOOP 2DUP OR WHILE 2OVER D+
> >> .S KEY DROP \ Can leave this out
> >> 2SWAP REPEAT ;
>
> Make that correct by
> 2SWAP REPEAT 1 . ;
>
> >> "
> >>
> >> 3.141592653589793238
> >> 1.000000000000000000
> >> 2DUP D. 2OVER D. KEY DROP .cf2
> >
> >You don't know what continued fractions are
>
> Said the cab-driver to the mathematician
>
> > --- your code is nonsense ---
> It gives the same results as your code, except for the correction
> I gave.
>
> > you posted this as a loyalty demonstration to Elizabeth Rather.
> I must say, I feel a connection with ER, like we are in the
> same camp or something.

So, in the year 2018 we still have loyal followers of Elizabeth Rather saying that D/ is not needed for continued-fractions.
Albert van der Horst says: "You only need D- and D<=." Then he posts some nonsense code that doesn't do anything. Very weird! This is cult behavior!
Well, that is certainly: "thinking differently!" LOL

[dxf...@gmail.com]

Organizations often falter under the weight of self-interest. Least able
to move on are those who having made decisions long ago cannot change for
fear losing customers. What existed initially to provide stability and
certainty inevitably becomes a prison.

>
> No one is compelled to use any standard other than by the advantages of that
> standard. If there are not sufficient advantages for a standard to be used
> by anyone or on any project it won't be used. If the advantages are
> sufficient then the standard is used.
>
> Seems like a workable arrangement to me.

Not looking to put anyone on the spot but ISTM those behind Standard
Forth should be able to demonstrate they've written substantive portable
applications using it. If not them, then who?

>
> Rick C.

[Paul Rubin]

dxf...@gmail.com writes:
> Not looking to put anyone on the spot but ISTM those behind Standard
> Forth should be able to demonstrate they've written substantive portable
> applications using it. If not them, then who?

I don't have the impression that code portability is/was a big goal.
It's more like programmer portability. Embedded targets in particular
are quirky and unique enough that there's not much hope of running
portable code on them. So Standard Forth implementations aren't
expected to be "run everywhere" like the JVM. They're only supposed to
be similar enough that programmers can switch around between them
without having to relearn too much.

[hughag...@gmail.com]

I have said, literally dozens of times, that Traditional Forth is for desktop-computers, not micro-controllers.
I have said, literally dozens of times, that Traditional Forth's primary purpose is to support cross-compilers.
Obviously, cross-compilers run on desktop-computers.

Straight Forth is a step up from Traditional Forth in that it not only supports cross-compilers, but also supports numeric and text-processing programs.
A major feature is quotations, which are for general-purpose data-structures --- obviously this is desktop-computer programming.

A major problem with ANS-Forth is that it tries to be the Forth standard for both desktop-computers and micro-controllers, which makes no sense at all.
This is just Elizabeth Rather the marketing genius saying: "Um, ANS-Forth is the standard for all Forth programming, from the 65c02 up to the Pentium."
This is just marketing blather --- this is why nobody takes ANS-Forth seriously --- ANS-Forth is a marketing gimmick with no technical merit whatsoever.

I think gForth was purposely crippled so the code would be half as fast as the abysmally slow SwiftForth --- so as to not make SwiftForth look bad.
The goal here was "portable programmers." Students could learn basic concepts such as what the data-stack is, before getting hired at Forth Inc..
Forth Inc. was tired of hiring employees who don't know what DUP and SWAP do, then putting them through the novice class that supposedly teaches everything,
and then finding that they still don't know anything about Forth and it is too expensive to pay them for the year or five that is needed to learn Forth.
So, the students are expected to learn what DUP and SWAP do in gForth on their own time, then become "portable programmers" moving into Forth Inc..
Now that Stephen Pelc has taken over Forth-200x, he has the same plan except that the students will move into MPE rather than Forth Inc..

I don't think this plan is going to work!
Forth Inc. ended up with John Passaniti who only knew Perl, but just enjoyed pretending to be a Forth expert on comp.lang.forth.
MPE ended up with Alex McDonald who "does standards for a living" (whatever the hell that means).
No Forth programmer with any pride whatsoever is going to put up with ANS-Forth or Forth-200x, both of which are pure crap from a technical perspective.

I think my rquotations totally destroy the credibility of Forth-200x.
There is no realistic argument in favor of the fake quotations that lack access to the parent function's local variables (while the HOF has locals of its own).
Endlessly arguing in favor of the fake quotations, which are obviously crippled, makes the Forth-200x committee look stupid or dishonest or both.

[gnuarm.del...@gmail.com]

On Sunday, November 4, 2018 at 9:17:29 PM UTC-5, hughag...@gmail.com wrote:
> Well, that is certainly: "thinking differently!" LOL

I snipped much lunacy and rambling that was approaching manifesto length. You know what happens to people who have manifestos.

Rick C.

[Anton Ertl]

Paul Rubin <no.e...@nospam.invalid> writes:
>dxf...@gmail.com writes:
>> Not looking to put anyone on the spot but ISTM those behind Standard
>> Forth should be able to demonstrate they've written substantive portable
>> applications using it. If not them, then who?
>
>I don't have the impression that code portability is/was a big goal.
>It's more like programmer portability.

Different participants have different goals. For me, program
portability is a big goal, and programmer portability is a bad joke.

>So Standard Forth implementations aren't
>expected to be "run everywhere" like the JVM. They're only supposed to
>be similar enough that programmers can switch around between them
>without having to relearn too much.

JVM implementations don't run everywhere, either. And a Standard
Forth program runs on every Standard Forth system (resources
permitting). However, the expressive power of Standard Forth is
severely limited. Some sugarcoat this as "programmer portability",
some try to do something about that by making more standard, some use
that as an argument against standardization, and some don't care about
standardization.

[Albert van der Horst]

In article <2018Nov...@mips.complang.tuwien.ac.at>,
Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
<SNIP>

>JVM implementations don't run everywhere, either. And a Standard
>Forth program runs on every Standard Forth system (resources
>permitting). However, the expressive power of Standard Forth is
>severely limited. Some sugarcoat this as "programmer portability",
>some try to do something about that by making more standard, some use
>that as an argument against standardization, and some don't care about
>standardization.

You forget the most important and most likely to succeed approach in
portability.
Some try to make compatible libraries with the same API for different
architectures. They are useful from day one, but they must be hugely
successful to have even the slightest chance to make it in the
standard.

>
>- anton

Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[hughag...@gmail.com]

On Monday, November 5, 2018 at 5:46:30 AM UTC-7, Anton Ertl wrote:
> And a Standard
> Forth program runs on every Standard Forth system

Anton Ertl seems to have forgotten what the topic of the thread is.
My early-binding MACRO: written in 2009 ran under SwiftForth but crashed under gForth --- so Anton Ertl said that I don't understand ANS-Forth.
He also invented the disambiguifiers as a solution.

Now Stephen Pelc says that the disambiguifiers don't solve the problem of FIND and tick being ambiguous. That is the topic of the thread!

The following was posted at the beginning of this thread:

On Tuesday, August 14, 2018 at 3:11:38 PM UTC-7, hughag...@gmail.com wrote:
> On Monday, January 1, 2018 at 5:24:35 PM UTC-7, hughag...@gmail.com wrote:
> > For a long time I believed that the above problems with FIND made ANS-Forth unusable. Then I remembered the disambiguifiers that Anton Ertl invented:
> >
> > : if state @ 0= if cr ." WARNING: *** no interpretation semantics for: IF ***" cr then
> > postpone if ; immediate
> >
> > This fixes all of the problems with FIND listed above! The disambiguifiers are the heart and soul of ANS-Forth programming!
>

> Anton Ertl invented disambiguifiers in 2009 in this thread:
>
> https://groups.google.com/forum/#!topic/comp.lang.forth/wP5nw1ClzsM%5B1-25%5D
>

> Note that in this thread Anton Ertl is criticizing me for expecting FIND and tick to behave the same way in every ANS-Forth system.
> He is telling me that FIND and tick have multiple incompatible behaviors, all of which are allowed by ANS-Forth.
> He is criticizing me for failing to anticipate that my early-binding MACRO: that ran under SwiftForth would crash under gForth.
>

> On Thursday, November 26, 2009 at 3:24:06 AM UTC-7, Anton Ertl wrote:
> > Hugh Aguilar <hugoa...@rosycrew.com> writes:
> > IF and ";" are not immediate words in the standard. A system can
> > implement them as immediate words, but a program cannot rely on their
> > immediacy.
> >
> > >I looked up ['] in the ANS-Forth document and it says:
> > >
> > >"Place name's execution token xt on the stack."
> >

> > What's the execution token of a word that has no execution semantics?

> >
> > Hmm, since you think that ";" is immediate, I guess you want an
> > execution token that, when executed, performs the compilation
> > semantics. You can get that as follows. Before the rest of the
> > program, define:
> >
> > : ; postpone ; ; immediate
> >
> > Now you have an immediate ";" with an execution semantics that's the
> > same as the compilation semantics, and you can tick it.
> >
> > >What I am saying is that I didn't have any warning that what I was
> > >doing in MACRO: was going to be a problem.
> >
> > A system that would tell us all non-standard usages would be nice, but
> > we don't have that. For now the solution is to test on as many
> > systems as possible.
>

[Anton Ertl]

alb...@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <2018Nov...@mips.complang.tuwien.ac.at>,
>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
><SNIP>
>>JVM implementations don't run everywhere, either. And a Standard
>>Forth program runs on every Standard Forth system (resources
>>permitting). However, the expressive power of Standard Forth is
>>severely limited. Some sugarcoat this as "programmer portability",
>>some try to do something about that by making more standard, some use
>>that as an argument against standardization, and some don't care about
>>standardization.
>
>You forget the most important and most likely to succeed approach in
>portability.
>Some try to make compatible libraries with the same API for different
>architectures.

Architectures? The issue at hand is portability of code between
different Forth systems.

Sure, if I want to use a non-standard feature in a program (e.g.,
knowledge of the current source line location in order to report the
source line for errors that your program detects only later on), I
could write a Gforth-specific piece of code for doing it, and a
SwiftForth-specific piece of code, and code for deciding whether the
program is being run on Gforth, SwiftForth, or something else. But if
that program is run on something else, the program will not make use
of that feature, and if that feature is required, the whole program
will not work.

So this is the approach to get a limited amount of portability in the
absence of standardization.

At least we have a standard way to do conditional text interpretation.

>They are useful from day one, but they must be hugely
>successful to have even the slightest chance to make it in the
>standard.

I think what you mean is that you publish an API with a reference
implementation for several systems, and you think it must be popular
to have a chance to make it into the standard.

My impression is that popularity is not a major concern for many
members of the Forth200x committee: You can have a proposal like
<http://www.forth200x.org/char-is-1.html> that is used by a large
number of programs and is implemented by all widely-used systems, and
the committee decided that they needed more time when it was first
decided (eventually it got through). OTOH, there is
<http://www.forth200x.org/text-substitution.txt> which AFAICT has not
even seen a CfV (i.e., a way to determine popularity), which AFAICT is
only used by the customers of a single vendor, and that made it into
the standard.

[a...@littlepinkcloud.invalid]

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:

> My impression is that popularity is not a major concern for many
> members of the Forth200x committee: You can have a proposal like
> <http://www.forth200x.org/char-is-1.html> that is used by a large
> number of programs and is implemented

Does doing nothing really count as "implementation"?

> by all widely-used systems, and the committee decided that they
> needed more time when it was first decided (eventually it got
> through). OTOH, there is
> <http://www.forth200x.org/text-substitution.txt> which AFAICT has
> not even seen a CfV (i.e., a way to determine popularity), which
> AFAICT is only used by the customers of a single vendor, and that
> made it into the standard.

Clearly, popularity is important, but it cannot be the only concern.
char-is-1 was was a breaking change so it deserved careful
contemplation. Also, there was no hurry: all of the portable programs
that assumed it would carry on working, and no-on would be impeded by
a delay.

Andrew.

[lsng....@gmail.com]

On Tuesday, November 6, 2018 at 10:41:02 PM UTC+8, Anton Ertl wrote:

> ....@....nl (Albert van der Horst) writes:
> Architectures? The issue at hand is portability of code between
> different Forth systems.
>
> Sure, if I want to use a non-standard feature in a program (e.g.,
> knowledge of the current source line location in order to report the
> source line for errors that your program detects only later on), I
> could write a Gforth-specific piece of code for doing it, and a
> SwiftForth-specific piece of code, and code for deciding whether the
> program is being run on Gforth, SwiftForth, or something else. But if
> that program is run on something else, the program will not make use
> of that feature, and if that feature is required, the whole program
> will not work.
>
> So this is the approach to get a limited amount of portability in the
> absence of standardization.
>
> At least we have a standard way to do conditional text interpretation.

I hope to get your attention about my project in another thread:

https://groups.google.com/d/msg/comp.lang.forth/45jIgX0z_24/POo_44COAwAJ

I have added the myjs_system() example from hello-spidermonkey github repo to my js.cpp.

https://github.com/udexon/fire4x/blob/master/js.cpp line 1746

I have basically found a way to interface ("hack") Firefox into calling any C++ function (via dlopen()).

I would like your contribution so that we can call your Forth modules using my jsshell hack.

Someone will need to write a wrapper so that dlopen() can load Forth words.

Then perhaps the Firefox (or other browsers') extensions can be another platform to test Forth standardization.

Now is the best chance for Forth to get into the mainstream -- as WASM (WebAssembly) is still at its infancy -- not that it will grow into a real stack machine given its distorted DNA in Ocaml.

[hughag...@gmail.com]

On Saturday, September 8, 2018 at 8:06:13 PM UTC-7, hughag...@gmail.com wrote:

Here is a demonstration of my early-binding MACRO: working:

macro: <mmm> ( flag -- ) \ a demonstration of MACRO:
0= abort" *** MMM needs a non-zero flag to execute ***"
456 . s" Hello " type s| from: "the Great Hugh" (Stephen Pelc's term for me)| type cr
-1 if ." Note that raw ANS-Forth can't FIND words like IF without the disambiguifiers." cr then
[char] A . ['] + .
c" I have ['] working." count type cr ;

: mmm ( -- )
123 . -1 <mmm> 789 . ;

mmm 123 456 Hello from: "the Great Hugh" (Stephen Pelc's term for me)
Note that raw ANS-Forth can't FIND words like IF without the disambiguifiers.
65 4230728 I have ['] working.
789 ok
' + . 4230728 ok

[hughag...@gmail.com]

Well, I looked up the ]] definition:
http://theforth.net/package/compat/current-view/macros.fs

This is actually ANS-Forth not Forth-200x.
Anton Ertl is avoiding the use of FIND because FIND is broken in ANS-Forth.
I don't know if FIND is also broken in Forth-200x.
I don't really care if Forth-200x has made incremental improvements to ANS-Forth
such as making FIND work correctly.
Forth-200x has many new problems that ANS-Forth didn't have,
such as recognizers and the fake quotations, so Forth-200x isn't worth looking at.

The obvious way to do this is to FIND the words and then meta-compile the XT.
The obvious advantage of this is that if FIND says that the word
is not in the dictionary, then the word can be given to STR>NUM to determine
if it is a literal number.

Anton Ertl can't use FIND though because FIND is broken in ANS-Forth.
FIND fails to work properly on 50 some words in the ANS-Forth standard,
such as IF etc..
Also, ANS-Forth is ambiguous in regard to whether words such as IF etc.
are immediate or non-immediate.
The disambiguifiers that Anton Ertl invented fix the problem with FIND
but Anton Ertl nowadays refuses to acknowledge the disambiguifiers.
Most likely, Elizabeth Rather demoted Anton Ertl from the chair
of the Forth-200x committee as a punishment for inventing the disambiguifiers.
Now Anton Ertl has to pretend that the disambiguifiers don't exist,
because the next step down for him would be to get demoted from the
Forth-200x committee entirely.
Then Anton Ertl would just be a mere Forth-200x mailing-list sycophant
at the same level as Alex McDonald.
If he then continued to say that disambiguifiers exist, the next step down
would be for him to get kicked off the Forth-200x mailing list.
Then he would be at the same level as me! There is no step down from this...
Anton Ertl wants to be an influential Forth-200x internet expert, so he just
pretends that the disambiguifiers don't exist.
This is what Elizabeth Rather demands --- purposeful ignorance!
If you aren't already a retard, then fake it!

Anyway, here is an implementation that relies on the disambiguifiers and
hence is able to use FIND in the obvious way.
I have INLINE: instead of ]] and ; instead of [[
The ]] ... [[ brackets are confusing because they point outwards rather than inwards.
I have LIT: DLIT: FLIT: "LIT: instead of ]]L ]]2L ]]FL ]]SL

Here is an example of the code being tested:
----------------------------------------------------------------------------
: test s" hello " "lit: type 123 . [char] A . s| Elizabeth "the Pope" Rather | type ; 456 . ; immediate ok
: ttt -1 . test -2 . ; 456 ok
ttt -1 hello 123 65 Elizabeth "the Pope" Rather -2 ok
----------------------------------------------------------------------------

Here is the code:
----------------------------------------------------------------------------
: sure-word ( char -- str ) \ like WORD except won't return an empty string if at the end of a line
locals| char |
begin char word dup c@ 0= while
drop
refill 0= abort" *** SURE-WORD ran out of source-code ***"
repeat ;

variable 'special-macro:

: special-macro: ( xt -- xt | 0 ) \ returns 0 if xt was special-cased
case
['] \ of postpone \ 0 exit endof
['] ( of postpone ( 0 exit endof
['] c" of postpone c" postpone lit, 0 exit endof
['] s" of postpone s" postpone dlit, 0 exit endof
['] ." of postpone s" postpone dlit, postpone type, 0 exit endof
['] abort" of postpone if,
postpone s" postpone dlit, postpone type,
postpone abort, postpone then, 0 exit endof
exit endcase ; \ -- xt \ EXIT with xt if it was never special-cased

' special-macro: 'special-macro: !

\ Note that C" S" and S| will be written later and will have to be special-cased again at that time.
\ Any time that immediate words that consume input-stream data are written, they have to be special-cased.

: check-macro: ( -- )
state @ 0= if cr ." WARNING: *** no interpretation semantics for MACRO: words ***" cr then ;

: inline: ( -- ) \ terminates on ; which is an immediate word
begin
bl sure-word find \ -- str 0 | xt 1 | xt -1 \ the 1 means immediate, -1 means non-immediate
?dup if
-1 = if
postpone literal postpone compile,
else
dup ['] ; = if drop exit then \ we terminate when we get to the ;
'special-macro: @ execute ?dup if postpone literal postpone execute then
then
else
count str>num case
#single of postpone literal postpone lit, endof
#double of postpone 2literal postpone dlit, endof
#float of postpone fliteral postpone flit, endof
true abort" *** INLINE: didn't recognize the string ***" endcase \ this is presumably #INVALID
then
again ;
immediate

: lit: ( n -- )
postpone lit, postpone inline: ;
immediate

: dlit: ( d -- )
postpone dlit, postpone inline: ;
immediate

: flit: ( -- ) \ float: n --
postpone flit, postpone inline: ;
immediate

: "lit: ( adr cnt -- ) \ use DLIT: instead if you know the string is already in the dictionary and immutable
postpone "lit, postpone inline: ;
immediate

\ INLINE: LIT: DLIT: FLIT: "LIT: are used inside of immediate words that meta-compile.
\ This is similar to ]] but a lot better because it supports literals
\ and immediate words such as [CHAR] etc. that take data out of the input stream.

: macro: ( -- )
:
postpone check-macro:
postpone inline: \ INLINE: had to be made immediate so it could be used directly in colon words
postpone ;
immediate
;

----------------------------------------------------------------------------

[hughag...@gmail.com]

On Thursday, December 27, 2018 at 2:58:19 AM UTC-7, hughag...@gmail.com wrote:
> Well, I looked up the ]] definition:
> http://theforth.net/package/compat/current-view/macros.fs

If we assume that understanding how FIND works in ANS-Forth is the threshold
to becoming an intermediate-level ANS-Forth programmer,
then Anton Ertl has posted novice-level code on www.theforth.net
According to the website homepage, the purpose is that Forthers can:
"Share your wonderful piece of Forth with the world."
So, Anton Ertl has disgraced the Forth community with his novice-level
schlock presented as being "wonderful" when it is not even intermediate-level.

Anton Ertl disgraced the Forth community with novice-level ANS-Forth code
because he was obligated to avoid using FIND because he needs
to support Stephen Pelc the liar in saying that the disambiguifiers don't work.
By "needs to" I mean that he will get kicked off the Forth-200x committee
if he tells the truth and says that the disambiguifiers do work.
He has already been demoted from Forth-200x chair-person to mere committee
member as a punishment for inventing the disambiguifiers in 2009.

I made a minor upgrade to my early-binding MACRO: code.
I changed the name of INLINE: to POST: which is possibly more readable.
POST: ... ; can be used in immediate words to meta-compile Forth code
similar to how ]] ... [[ is used.

My POST: etc. is, of course, far superior to Anton Ertl's novice-level ]] etc..
I support immediate words such as ['] [char] s" ." abort" etc. that remove
data from the input stream.

Another minor upgrade I made was to support POSTPONE also.
This is another immediate word that removes data from the input stream.
I had forgotten to support it previously.
Supporting POSTPONE is, of course, impossible in ]] because FIND is needed.

This is a test of the code doing a POSTPONE of a non-immediate word:
---------------------------------------------------------------------------
macro: ttt postpone . ; ok
: ttt1 ttt ; immediate ok
: ttt2 12345 ttt1 ; ok
ttt2 12345 ok
---------------------------------------------------------------------------

This is a test of the code doing a POSTPONE of an immediate word:
---------------------------------------------------------------------------
macro: sss postpone if ; ok
: sss1 sss post: 123 . else 456 . then ; ; immediate ok
: sss2 sss1 ; ok
1 sss2 123 ok
0 sss2 456 ok
---------------------------------------------------------------------------

This is the code:

---------------------------------------------------------------------------
: sure-word ( char -- str ) \ like WORD except won't return an empty string if at the end of a line
locals| char |
begin char word dup c@ 0= while
drop
refill 0= abort" *** SURE-WORD ran out of source-code ***"
repeat ;

: meta-compile, ( -- )
postpone compile, ;

: meta-postpone ( -- ) \ stream: name
bl word find dup 0= abort" *** META-POSTPONE couldn't find the name ***"
1 = if \ immediate
lit, postpone compile,
else \ non-immediate
lit, postpone lit, postpone meta-compile,
then ;

variable 'special-macro:

: special-macro: ( xt -- xt | 0 ) \ returns 0 if xt was special-cased
case

['] postpone of meta-postpone 0 exit endof

['] \ of postpone \ 0 exit endof
['] ( of postpone ( 0 exit endof

['] ['] of postpone ['] postpone lit, 0 exit endof
['] [char] of postpone [char] postpone lit, 0 exit endof

['] c" of postpone c" postpone lit, 0 exit endof
['] s" of postpone s" postpone dlit, 0 exit endof
['] ." of postpone s" postpone dlit, postpone type, 0 exit endof
['] abort" of postpone if,
postpone s" postpone dlit, postpone type,
postpone abort, postpone then, 0 exit endof
exit endcase ; \ -- xt \ EXIT with xt if it was never special-cased

' special-macro: 'special-macro: !

\ Note that C" S" and S| will be written later and will have to be special-cased again at that time.
\ Any time that immediate words that consume input-stream data are written, they have to be special-cased.

: check-macro: ( -- )
state @ 0= if cr ." WARNING: *** no interpretation semantics for MACRO: words ***" cr then ;

: post: ( -- ) \ terminates on ; which is an immediate word

begin
bl sure-word find \ -- str 0 | xt 1 | xt -1 \ the 1 means immediate, -1 means non-immediate
?dup if
-1 = if
postpone literal postpone compile,
else
dup ['] ; = if drop exit then \ we terminate when we get to the ;
'special-macro: @ execute ?dup if postpone literal postpone execute then
then
else
count str>num case
#single of postpone literal postpone lit, endof
#double of postpone 2literal postpone dlit, endof
#float of postpone fliteral postpone flit, endof

true abort" *** POST: didn't recognize the string ***" endcase \ this is presumably #INVALID

then
again ;
immediate

: lit: ( n -- )

postpone lit, postpone post: ;

immediate

: dlit: ( d -- )

postpone dlit, postpone post: ;

immediate

: flit: ( -- ) \ float: n --

postpone flit, postpone post: ;

immediate

: "lit: ( adr cnt -- ) \ use DLIT: instead if you know the string is already in the dictionary and immutable

postpone "lit, postpone post: ;
immediate
---------------------------------------------------------------------------

Whenever new immediate words are written that remove data from the
input stream, they must be special-cased in a new SPECIAL-MACRO: word.
This is an example:
---------------------------------------------------------------------------
\ In Gforth, C" doesn't work in interpretive mode, so here is one that does.
\ This is a huge help when testing functions that take counted strings as arguments.

\ I didn't write a function that would use an arbitrary delimiter, because ANS-Forth only provides SLITERAL,
\ but nothing similar for counted strings.

: special-macro: ( xt -- xt | 0 ) \ returns 0 if xt was special-cased

[ 'special-macro: @ ] literal execute dup 0= if exit then
case
['] string of postpone string postpone dlit, 0 exit endof

['] s| of postpone s| postpone dlit, 0 exit endof
['] s" of postpone s" postpone dlit, 0 exit endof
['] c" of postpone c" postpone lit, 0 exit endof

exit endcase ; \ -- xt \ EXIT with xt if it was never special-cased

' special-macro: 'special-macro: !

\ STRING S| S" and C" all needed to be special-cased in MACRO: so SPECIAL-MACRO: had to be upgraded with these.
\ It is okay that S" and C" are in the original SPECIAL-MACRO: too, because they won't match.
\ The xt given here will be of the new version (because FIND finds the latest version) and won't match the old xt in the original SPECIAL-MACRO:
---------------------------------------------------------------------------

[hughag...@gmail.com]

Here is yet another example of Stephen Pelc's dishonesty:

On Sunday, January 27, 2019 at 11:10:14 AM UTC-7, Alex McDonald wrote:
> On 27-Jan-19 04:06, dxf...@gmail.com wrote:
> > There is a qualification requirement before one can sit on the Forth
> > Standards committee?
>
> What qualification would you recommend?
>
> https://forth-standard.org/standard/members-2x

If we look at that webpage, we find this:
"Dr. Peter Knaggs (Editor) Independent Member"

But there is Stephen Pelc's webpage:
https://www.mpeforth.com/sample-page/46-2/
We find Peter Knaggs listed as an employee of MPE:
"Peter is the part of the toolmaking team that tells us how to do it properly."

So, an MPE employee is an "independent member" of the Forth-200x committee???
Forth-200x is really astro-turf --- a corporate marketing gimmick
faked up to look like a grassroots project.

Similarly, we find Andrew Haley listed:
"Andrew Haley Red Hat UK Ltd."
Andrew Haley's Forth experience was to teach the novice-class
for Forth Inc.. He seems to have no purpose in life except to
agree with Elizabeth Rather on everything that she says.
He is not independent either. He is Elizabeth Rather's brown-noser.

Ed (DXForth) asked what qualification requirements are needed
to sit on the Forth-200x Standard Committee.
I would recommend a pair of knee-pads and a big bottle of mouthwash.

[hughag...@gmail.com]

On Thursday, December 27, 2018 at 2:58:19 AM UTC-7, hughag...@gmail.com wrote:

Anton Ertl is still promoting his ridiculous ]] ... [[ construct!!!
The guy just doesn't have any self-respect whatsoever!

On Tuesday, March 19, 2019 at 6:56:12 AM UTC-7, Anton Ertl wrote:
> Helmar Wodtke <hel...@gmail.com> writes:
> >It's also more readable.
>
> True. Another readable variant is
>
> ]] foo bar bla [[
> > What are the exact advantages of POSTPONE I do not see in real use.
>
> It's standardized. A number of people have picked up ]] ... [[,
> though.

Who exactly are these "number of people" that Anton Ertl brags about?
Do they have names?
Or should we just identify them by their scuffed knees?
Anton Ertl is pretending that ANS-Forth and Forth-200x is a large
grassroots movement. It isn't.
The number of people who care about ANS-Forth and Forth-200x is less
than 20, and very few of them are actual programmers.
Most of them are like Alex McDonald who "does standards for a living"
(whatever the hell that means) but can't actually program in Forth.

Certainly the only virtue of ]] ... [[ is that Anton Ertl used a goofy
contorted technique to avoid using FIND that is ambiguous.
He didn't use FIND because doing so would have offended Elizabeth Rather
and Stephen Pelc (because they hate the needed disambiguifiers).
Elizabeth Rather screwed up FIND in 1994 and now, in 2019, her disgusting
sycophant Anton Ertl is striving mightily to avoid mentioning that
FIND is ambiguous, and he is avoiding fixing FIND with the disambiguifiers.
Of course, Anton Ertl's code is crap.
His ]] ... [[ fails badly because it doesn't support immediate words
such as ['] [CHAR] POSTPONE ." etc. that remove data from the input stream.
My POST: does support all of these words, which is easy to do.
(note that I originally called it INLINE: but then switched to POST:
that may be somewhat more readable).
POST: is used internally by MACRO: that I use quite a lot.

This is a practical example:
-------------------------------------------------------------------
SwiftForth? [if]

icode next>r ( node -- node ) \ r: -- next-node
0 [ebx] push
ret end-code

[else]

macro: next>r ( node -- node ) \ r: -- next-node
dup .fore @ >r ;

[then]

macro: each[ \ toucher: i*x node -- j*x
begin dup while
next>r ;

macro: ]each
r> repeat drop ;
-------------------------------------------------------------------

[hughag...@gmail.com]

On Sunday, September 30, 2018 at 10:16:51 PM UTC-7, hughag...@gmail.com wrote:
> On Saturday, September 8, 2018 at 8:06:13 PM UTC-7, hughag...@gmail.com wrote:

> > Disambiguifiers will utterly destroy the credibility of the ANS-Forth cult --- this is because they become blatant liars ---
> > they can't admit that FIND in ANS-Forth is ambiguous because doing so requires them to admit that Elizabeth Rather is an idiot.
> > Refusing to admit a mistake, even after a solution to the mistake has been provided, is the hallmark of a cult.
>
> Well, I have searched through comp.lang.forth looking for anybody who publicly agrees with Stephen Pelc regarding the disambiguifiers.
> So far, I have only found Rickman to do so.
> Everybody else dodges the issue. They don't want to publicly agree with Stephen Pelc because they know that Stephen Pelc is lying.
> They don't want to publicly state that Stephen Pelc is lying though, because then Stephen Pelc will kick them off the Forth-200x mailing-list,
> and they won't get to be internet-experts anymore --- so they just tacitly support Stephen Pelc's lies, without fully committing themselves.
>
> Here is brave Rickman fully committing himself to supporting Stephen Pelc's lies:
>
> On Sunday, August 6, 2017 at 8:08:23 PM UTC-7, hughag...@gmail.com wrote:
> > On Tuesday, August 1, 2017 at 2:27:41 AM UTC-7, Stephen Pelc wrote:
> > > On Tue, 18 Jul 2017 21:28:18 -0700 (PDT), hughag...@gmail.com
> > > wrote:
> > >
> > > >My complaint against Stephen Pelc is that he uses dishonest business practi=
> > > >ces. He supports ANS-Forth and Forth-200x for the purpose of making all For=
> > > >th programmers look stupid. He doesn't actually use ANS-Forth himself. He r=
> > > >outinely provides vendor-specific code in VFX, even when it is easy to writ=
> > > >e the code in ANS-Forth, for the purpose of trapping his customers in vendo=
> > > >r lock-in. A good example is SYNONYM --- I can write this in ANS-Forth usin=
> > > >g my disambiguifiers --- he insists that this is impossible to write in ANS=
> > > >-Forth --- he refuses to admit that the disambiguifiers exist because he wa=
> > > >nts ANS-Forth's FIND to behave differently in every ANS-Forth compiler.
> > >
> > > Hugh's wonderful disambiguifiers do NOT do what the great Hugh thinks
> > > they do. What the great Hugh has done is to redefine a large number of
> > > words so that they behave in a very restricted way to support the
> > > great Hugh's version of Forth. Hugh's SYNONYM is not portable ANS
> > > Forth unless you use Hugh's Forth. Bah, humbug. Another emperor
> > > with no clothes.
> > >
> > > Stephen
> >
> > Stephen Pelc is another liar.
>
> On Monday, August 7, 2017 at 1:06:49 AM UTC-7, rickman wrote:
> > hughag...@gmail.com wrote on 8/6/2017 11:08 PM:
> > >
> > > Stephen Pelc is another liar.
> >
> > So to address Gerry and other's concerns that Hugh's insane comments that
> > appear to impune others, this is a perfect example. First Hugh responds to
> > Stephen (not Steven) on the subject matter of disambiguafiers. Then he
> > posts this simple, yet absurd statement.
> >
> > No one with a lick of sense would give Hugh any credibility. There is no
> > need to Hugh or involve him in a discussion of his delusions.
> >
> > Just get over him and ignore him instead of letting him involve you in his
> > fantasies.
> >
> > --
> >
> > Rick C

Here is another example of somebody publicly agreeing with
Stephen Pelc regarding the disambiguifiers:

On Sunday, March 31, 2019 at 8:21:04 AM UTC-7, Alex McDonald wrote:
> On 31-Mar-19 09:26, marek....@gmail.com wrote:
> > Dne neděle 31. března 2019 5:49:28 UTC+2 hughag...@gmail.com
> > napsal(a):
> >> The recognizers are a goofy technique to get rid of immediate words
> >> on a Forth system. This gets rid of immediate words such as S" IF
> >> etc. and instead has this functionality taken care of by a
> >> monolithic parser.
>
> None of these needs to be immediate. IF is not immediate in VFX; and S"
> is not immediate in my Forth. They both pass the Hayes' tests.
>
> The proposal is for a set of user defined parsers, executed one after
> the other until the string is recognized. How's that monolithic?

Alex McDonald says that ANS-Forth allows IF to be immediate
in some ANS-Forth systems (SwiftForth) and non-immediate
in some ANS-Forth systems (VFX) and all of this passes
the Hayes' test so it is hunky-dory.

This is ambiguity!
My disambiguifiers fix this ambiguity.
Stephen Pelc was lying when he contradicted me on this.
Stephen Pelc is a liar who should never be trusted on anything again.

[Alex McDonald]

Once.

>>
>> On Monday, August 7, 2017 at 1:06:49 AM UTC-7, rickman wrote:
>>> hughag...@gmail.com wrote on 8/6/2017 11:08 PM:
>>>>
>>>> Stephen Pelc is another liar.

Twice.

I see you didn't address the point about your claim that the recognizer
proposal is monolithic, or prevents writing cross compilers. I don't
think you understand the proposal sufficiently well to make these claims.

>
> Alex McDonald says that ANS-Forth allows IF to be immediate in some
> ANS-Forth systems (SwiftForth) and non-immediate in some ANS-Forth
> systems (VFX) and all of this passes the Hayes' test so it is
> hunky-dory.
>
> This is ambiguity!

I have a vision of you as Gerard Butler in the 300 shouting "This is
Sparta!".

IF does not have defined interpretation semantics
; and undefined is not a synonym for ambiguous. The standard says
nothing about the immediacy of IF. It never has, and it doesn't need to.
It is an implementation detail, and standards shouldn't describe
implementation.

> My disambiguifiers fix this ambiguity.

It's only ambiguous if you think immediacy needs to be defined for each
and every word, and that every word has to have both interpretation and
compilation semantics, and that state-smart is OK. Your
"disambiguifiers" don't fix these problems.

> Stephen Pelc was lying when he contradicted me on this. Stephen Pelc

Three times.

> is a liar who should never be trusted on anything again.

Four times in one post.

I see you still can't discuss technical points here without descending
into ranty shouting calling folks liars or worse. Said face to face
these kind of statements would get you a well deserved burst lip. Why do
you think you can say these things here?

--
Alex

[hughag...@gmail.com]

On Monday, April 1, 2019 at 1:37:30 AM UTC-7, Alex McDonald wrote:
> On 01-Apr-19 05:42, hughag...@gmail.com wrote:
> > On Sunday, September 30, 2018 at 10:16:51 PM UTC-7,
> > hughag...@gmail.com wrote:
> > Here is another example of somebody publicly agreeing with Stephen
> > Pelc regarding the disambiguifiers:
> >
> > On Sunday, March 31, 2019 at 8:21:04 AM UTC-7, Alex McDonald wrote:
> >> On 31-Mar-19 09:26, marek....@gmail.com wrote:
> >>> Dne neděle 31. března 2019 5:49:28 UTC+2 hughag...@gmail.com
> >>> napsal(a):
> >>>> The recognizers are a goofy technique to get rid of immediate
> >>>> words on a Forth system. This gets rid of immediate words such
> >>>> as S" IF etc. and instead has this functionality taken care of
> >>>> by a monolithic parser.
> >>
> >> None of these needs to be immediate. IF is not immediate in VFX;
> >> and S" is not immediate in my Forth. They both pass the Hayes'
> >> tests.
> >>
> >> The proposal is for a set of user defined parsers, executed one
> >> after the other until the string is recognized. How's that
> >> monolithic?
>
> I see you didn't address the point about your claim that the recognizer
> proposal is monolithic, or prevents writing cross compilers. I don't
> think you understand the proposal sufficiently well to make these claims.

Alex McDonald is a semi-literate sales clown!
He doesn't know that the word "set" implies that the elements are unordered.

The recognizes are essentially a monolithic sub-language that parses
Forth source-code. Because there is a sequence of parsers, there will be
multiple incompatible monolithic sub-languages depending upon what
parsers are in the sequence and what order they are in.

This is very similar to how, in VFX, words like IF are non-immediate,
just like sub-functions, but they are being special-cased internally
because they aren't sub-functions --- they meta-compile some code into
the target, which has traditionally been the job of immediate words.

> IF does not have defined interpretation semantics
> ; and undefined is not a synonym for ambiguous. The standard says
> nothing about the immediacy of IF. It never has, and it doesn't need to.
> It is an implementation detail, and standards shouldn't describe
> implementation.
>
> > My disambiguifiers fix this ambiguity.
>
> It's only ambiguous if you think immediacy needs to be defined for each
> and every word, and that every word has to have both interpretation and
> compilation semantics, and that state-smart is OK. Your
> "disambiguifiers" don't fix these problems.

Immediacy needs to be defined for each word.
If a word may or may not be immediate, then it is ambiguous.
This is not an "implementation detail" --- this is behavior ---
obviously immediate and non-immediate words behave differently.
Anybody who doesn't understand this, doesn't understand Forth.
I think that people such as yourself want to turn Forth into
a scripting language with a syntax with your recognizers.
The world already has multiple scripting languages though,
with Python being the most popular; Factor is gaining popularity.
Forth is not a scripting language though.
I remember that I pointed out to Slava Pestov that Factor doesn't
support Forth cross-compilers because Factor doesn't have
immediate words. He agreed that this was true.

I don't think that every word needs to have both interpretation and
compilation action. That implies state-smart words immediate words.
Note that "semantics" is the wrong word in the English language;
Elizabeth Rather is a semi-literate sales-clown who used the word
"semantic" in the ANS-Forth document for pseudo-intellectual effect.

I also think that state-smart words are a very bad idea ---
the problems with state-smart words have been well-known for decades.

This is a disambiguifier:
--------------------------------------------------------------------
: if
state @ 0= if

cr ." WARNING: *** no interpretation semantics for: IF ***" cr
then
postpone if ;
immediate

--------------------------------------------------------------------

I originally had this written like this:
--------------------------------------------------------------------
: if
state @ 0= abort" *** no interpretation semantics for: IF ***"
postpone if ;
immediate
--------------------------------------------------------------------

I changed it to only give a warning, not to abort, because Anton Ertl
complained that having it abort prevented it from being used inside
of [ ... ] brackets, which is sometimes needed.
This was back when Anton Ertl was still the chair-person of Forth-200x
and still believed that he could admit that the disambiguifiers work.
Later on, Anton Ertl got demoted to mere committee member, presumably

as a punishment for inventing the disambiguifiers.

Stephen Pelc became the new Emperor of Forth-200x and after that
Anton Ertl stopped admitting that the disambiguifiers work.
Presumably if he continues to admit that the disambiguifiers work,
he will be punished again by getting kicked off the committee.
Then he will be a lowly Forth-200x mailing-list sycophant, like you!

One of the many utterly stupid mistakes that Elizabeth Rather made
in ANS-Forth was to not distinguish between interpreting inside of
[ ... ] brackets in colon words and interpreting outside of colon words.

The name STATE is confusing. I would have called it: INTERPRETING@
-1 interpreting outside of a colon word
0 compiling inside of a colon word
1 interpreting inside of [ ... ] in a colon word

Another stupid thing that Elizabeth Rather did, was to make STATE
a variable and then say this in the document:
"Note: A program shall not directly alter the contents of STATE."
It would have been better to have INTERPRETING@ that provides the
value of the state, but not provide the address of a variable that
can be changed. The user should never change it.

> > Stephen Pelc was lying when he contradicted me on this. Stephen Pelc
>
> Three times.
>
> > is a liar who should never be trusted on anything again.
>
> Four times in one post.
>
> I see you still can't discuss technical points here without descending
> into ranty shouting calling folks liars or worse. Said face to face
> these kind of statements would get you a well deserved burst lip. Why do
> you think you can say these things here?

You are threatening me with violence. That is typical of a cult!
Who is going to hit me in the mouth? You, or Stephen Pelc?
If it is Stephen Pelc, then I think he should do the threatening himself,
rather than have his sycophant do it for him.

If Stephen Pelc wants me to stop calling him a liar,
then he should stop lying. The disambiguifiers do work; that is the truth.
I am willing to call Stephen Pelc a liar to his face ---
both of you at the same time is fine with me --- a two-for-one special!

This is an email that I received from you:
-----------------------------------------------------------------------------
On Wed, Jun 8, 2016 at 2:29 PM, Alex McDonald <al...@rivadpm.com> wrote:
On 01/06/16 16:20, hughag...@gmail.com wrote:
> The RfD was going to be a slam-dunk from a ladder for Alex McDonald > --- but then Alex McDonald disappeared --- now the RfD is left in
> limbo while Anton and Bernd search for a new pocket-boy who will put
> his name on the RfD.

Then the Forth-200x committee had Alex McDonald pretending to represent
>the "Forth community," but Alex "I do standards for a living" McDonald
> disappeared. This is a chronic problem for the Forth-200x committee
> --- their pocket boys disappear --- then they have to find new
> pocket boys to put their names on the RfDs.

Unfortunately, you're still here, and I suspect you won't do me the tremendous favour of fucking off or dieing any time soon. Ah well.

I still occasionally read clf. Personal reasons and your continued existence have stopped me being an active contributor. I'll continue to lurk for the moment.

--
Alex "I still do standards for a living" McDonald
-----------------------------------------------------------------------------

Note that "pocket boy" was Ilya Tarasov's term for committee sycophants
such as yourself.
That is presumably Russian slang --- it is a good term for a sycophant.

[gnuarm.del...@gmail.com]

He had been no a roll of posting six messages with no reply other than to himself... until now.

:I

--

Rick C.

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

[gnuarm.del...@gmail.com]

On Monday, April 1, 2019 at 4:37:30 AM UTC-4, Alex McDonald wrote:

[Alex McDonald]

On 01-Apr-19 23:51, gnuarm.del...@gmail.com wrote:

>
> He had been no a roll of posting six messages with no reply other than to himself... until now.
>
> :I
>

Sorry. Marek replied to him, and I'm afraid I rose to his trolling.

But look where it got me! Apparently I'm a "semi-literate sales clown",
which is a considerably grander level of abuse than anything awarded to
Stephen Pelc, Anton Ertl, Andrew Haley or even the illustrious Elizabeth
Rather. I consider it a badge of honour.

--
Alex

[gnuarm.del...@gmail.com]

Maybe I don't get all the posts. I don't see one by Marek. I'm using Google Groups because I got tired of changing newsgroup readers when the software got messed up.

--

Rick C.

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

[Alex McDonald]

On 03-Apr-19 19:05, gnuarm.del...@gmail.com wrote:
> On Tuesday, April 2, 2019 at 4:17:03 PM UTC-4, Alex McDonald wrote:
>> On 01-Apr-19 23:51, gnuarm.del...@gmail.com wrote:
>>
>>>
>>> He had been no a roll of posting six messages with no reply other
>>> than to himself... until now.
>>>
>>> :I
>>>
>>
>> Sorry. Marek replied to him, and I'm afraid I rose to his
>> trolling.
>>
>> But look where it got me! Apparently I'm a "semi-literate sales
>> clown", which is a considerably grander level of abuse than
>> anything awarded to Stephen Pelc, Anton Ertl, Andrew Haley or even
>> the illustrious Elizabeth Rather. I consider it a badge of honour.
>
> Maybe I don't get all the posts. I don't see one by Marek. I'm
> using Google Groups because I got tired of changing newsgroup readers
> when the software got messed up.
>

It may not have been Marek. It was definitely Hugh though ;)

I use Thunderbird. If you don't use any of the fancy features, it's been
a pretty solid newsgroup reader for me.


--
Alex

[gnuarm.del...@gmail.com]

It worked well for me for some years, then crapped out and I couldn't get it working again without tossing all my history. So I tried Seamonkey which uses the same code base and I could import all the data from Tbird. Then after a couple of years it crapped out and I used Goggle temporarily which I am still doing some years later. Tbird and Seamonkey both would get cranky when the data base would get large. I'm just glad I never switched to either for my email.

Eudora may be old, but so far it has been extremely reliable.

--

Rick C.

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

[hughag...@gmail.com]

Recently we had this humorous exchange:

On Friday, April 26, 2019 at 9:44:00 AM UTC-7, gnuarm.de...@gmail.com wrote:
> On Friday, April 26, 2019 at 10:57:24 AM UTC-4, a...@littlepinkcloud.invalid wrote:
> If ANS is not simple, what Forth is??? Is the simplicity of the question too simple?
> ...
> Ask Hugh about getting an XT for some words. Seems they are so mode dependent they can't even be ticked or something.
> ...
> > It is certainly true that you have to stick with [Forth] until you have
> > that "aha!" moment when it all makes sense. This is true of every
> > skill, I think.
>
> BS on the "aha" nonsense.

Among the ANS-Forth cult, there is a lot of emphasis on the
supposed "aha!" moment when ANS-Forth suddenly makes sense.
The presumption is that, if you don't think that ANS-Forth
makes sense, this is because you have never had your "aha!" moment.
This is very similar to the Southern Suddenness school of Buddhism
in which a person becomes enlightened in a sudden "aha!" moment,
as compared to the Northern school in which enlightenment is a more
gradual process.
In general, people who are afraid of the gradual process, are afraid
of the effort required to learn a subject --- they imagine that
great knowledge will suddenly fill their empty heads --- they expect
knowledge as a reward for loyalty. This is not the way the world works.

Andrew Haley then replied:

On Friday, April 26, 2019 at 10:02:05 AM UTC-7, a...@littlepinkcloud.invalid wrote:
> gnuarm.del...@gmail.com wrote:
> > Ask Hugh
>
> No.

It is pathetic that the ANS-Forth cult are unable (unwilling)
to understand how FIND is broken in ANS-Forth and how
the disambiguifiers fix FIND so that it is usable.
If anybody tries to give them knowledge,
they close their eyes and cover their ears, and shout: "No!"
Fear of knowledge is the hallmark of a cult.

Andrew Haley worked at Forth Inc. teaching the novice-class.
Why didn't Elizabeth Rather explain to him how FIND is broken?
Well, the problem is that when Elizabeth Rather wrote the
ANS-Forth Standard she had little or no understanding of even
the most rudimentary aspects of Forth --- she didn't know how
FIND worked traditionally --- her ANS-Forth document is just
a muddled mess written by a non-programmer.

For a cult-member such as Andrew Haley, being an ANS-Forth
expert is all about having Elizabeth Rather declare him to be
an ANS-Forth expert --- it is not about technical knowledge.

[hughag...@gmail.com]

> On Tuesday, August 1, 2017 at 2:27:41 AM UTC-7, Stephen Pelc wrote:
> Hugh's wonderful disambiguifiers do NOT do what the great Hugh thinks
> they do. What the great Hugh has done is to redefine a large number of
> words so that they behave in a very restricted way to support the
> great Hugh's version of Forth. Hugh's SYNONYM is not portable ANS
> Forth unless you use Hugh's Forth. Bah, humbug. Another emperor
> with no clothes.
>
> Stephen

Here is another fun quote from Stephen Pelc:

On Tuesday, June 4, 2019 at 11:01:27 AM UTC-7, Stephen Pelc wrote:
> IMHO Forth is a difficult language, and requires good programmers for
> productive usage.

How will Stephen Pelc recognize good programmers when he sees them?
How did the Emperor recognize the good tailors when he saw them?

Stephen Pelc employed Peter Knaggs as a programmer,
but Peter Knaggs failed badly at implementing a linked-list.
His linked-list implementation had as much substance as
the Emperor's new clothes.

[hughag...@gmail.com]

Stephen Pelc recently started this thread:
https://groups.google.com/forum/#!topic/comp.lang.forth/IMYFTDHBjH8

On Friday, June 28, 2019 at 3:15:39 AM UTC-7, Stephen Pelc wrote:
> A new MPE client said:
> "A more generic question regarding Forth: I find the comp.lang.forth
> newsgroup to be quite toxic and unpleasant. Do you know of a more
> friendly environment where newbies can ask questions?"
>
> Stephen

This is Stephen Pelc who has never apologized to me for saying this:

> On Tuesday, August 1, 2017 at 2:27:41 AM UTC-7, Stephen Pelc wrote:
> Hugh's wonderful disambiguifiers do NOT do what the great Hugh thinks
> they do. What the great Hugh has done is to redefine a large number of
> words so that they behave in a very restricted way to support the
> great Hugh's version of Forth. Hugh's SYNONYM is not portable ANS
> Forth unless you use Hugh's Forth. Bah, humbug. Another emperor
> with no clothes.
>
> Stephen

This is the Stephen Pelc who recently contributed to this thread:
https://groups.google.com/forum/#!topic/comp.lang.forth/wNYAbr6ltTU

On Tuesday, June 25, 2019 at 3:35:43 PM UTC-7, Stephen Pelc wrote:
> On Tue, 25 Jun 2019 06:39:51 -0700 (PDT), hughag...@gmail.com
> wrote:
>
> >I don't know what they have in Africa, but I doubt that it is
> >any better than America, Europe, Russia, etc..
> >I stand by what I said.
> >There is nothing comparable in quality on any continent.
>
> You are just demonstrating your ignorance and your failure to
> accept that anyone else can do better than you.
>
> Stephen

He has not apologized for this either.

Of course, in both threads Stephen Pelc is either
demonstrating ignorance of Forth programming, or he is lying.

Stephen Pelc is wrong about the disambiguifiers.

Stephen Pelc has never presented any evidence to indicate
that he knows more about how to implement a string-stack
than a monkey knows about how to build a jet airplane.

Stephen Pelc just wants to be the chair-person of Forth-200x
(the Emperor of Forth), and he wants all Forthers to
get on their knees for him.
Stephen Pelc is failing badly at Forth programming though,
from a technical standpoint.

Stephen Pelc is toxic and unpleasant.
He just has too much ego investment.

[hughag...@gmail.com]

> On Tuesday, August 1, 2017 at 2:27:41 AM UTC-7, Stephen Pelc wrote:

> > On Tue, 18 Jul 2017 21:28:18 -0700 (PDT), hughag...@gmail.com
> > wrote:
> >
> > >My complaint against Stephen Pelc is that he uses dishonest business practi=
> > >ces. He supports ANS-Forth and Forth-200x for the purpose of making all For=
> > >th programmers look stupid. He doesn't actually use ANS-Forth himself. He r=
> > >outinely provides vendor-specific code in VFX, even when it is easy to writ=
> > >e the code in ANS-Forth, for the purpose of trapping his customers in vendo=
> > >r lock-in. A good example is SYNONYM --- I can write this in ANS-Forth usin=
> > >g my disambiguifiers --- he insists that this is impossible to write in ANS=
> > >-Forth --- he refuses to admit that the disambiguifiers exist because he wa=
> > >nts ANS-Forth's FIND to behave differently in every ANS-Forth compiler.
> >

> > Hugh's wonderful disambiguifiers do NOT do what the great Hugh thinks
> > they do. What the great Hugh has done is to redefine a large number of
> > words so that they behave in a very restricted way to support the
> > great Hugh's version of Forth. Hugh's SYNONYM is not portable ANS
> > Forth unless you use Hugh's Forth. Bah, humbug. Another emperor
> > with no clothes.
> >
> > Stephen

Here we have yet another Forther contradicting Stephen Pelc:

On Thursday, July 11, 2019 at 9:32:03 PM UTC-7, Ruvim wrote:
> On 2019-07-11 23:07, Alex McDonald wrote:
> > This one is probably for Anton, since the code is his.
> >
> > I'm was having problems running POSTPONETEST.FTH, in particular
> >
> > TESTING POSTPONE POSTPONE
> > : POSTPONE-POSTPONE
> > POSTPONE POSTPONE ;
> >
> > T{ : PPP1 123 ; -> }T
> > T{ : PPP4 [ POSTPONE-POSTPONE PPP1 ] ; IMMEDIATE -> }T
> > T{ : PPP5 PPP4 ; -> }T
> > T{ PPP5 -> 123 }T
> > T{ : PPP6 345 ; IMMEDIATE -> }T
> > T{ : PPP7 [ POSTPONE-POSTPONE PPP6 ] ; -> }T
> > T{ PPP7 -> 345 }T
> >
> > The compiler is miscompiling the line
> >
> > T{ : PPP4 [ POSTPONE-POSTPONE PPP1 ] ; IMMEDIATE -> }T
> >
> > and is compiling the ] instead of executing it; i.e. the STATE is wrong.
> > Here's my code, where STATE selects any of the interpretation (0),
> > compilation (-1) or postpone (-2) actions for a word.
> >
> > : ]] -2 state ! ; immediate \ start of postpone state
> >
> > : postpone ( -<name>- ) \ postpone next word
> > postpone ]]
> > parse-name default-recognize execute
> > ] ; immediate \ reset state to compilation
> >
> > POSTPONE-POSTPONE is being run in interpretation state. The fix is to:
> >
> > : postpone ( -<name>- ) \ postpone next word
> > state @ \ save state
> > postpone ]]
> > parse-name default-recognize execute
> > state ! ; immediate \ restore state
> >
> > My question; the standard specifies that there's no interpretation state
> > for POSTPONE. I was switching back into compilation state after the
> > postpone state, hence the miscompile. Am I misinterpreting the state
> > when POSTPONE-POSTPONE is being interpreted in PPP4?
> >
>
>
> 1. POSTPONE shall not change STATE (it may change it internally, but
> after its return STATE shall be the same as before call).
> Reason: "Only the following standard words alter the value in STATE: :
> (colon), ; (semicolon), ABORT, QUIT, :NONAME, [ (left-bracket), ]
> (right-bracket)" — citation from the specification of STATE.
>
>
> 2. "Interpretation semantics for this word are undefined" actually means
> that it is an ambiguous condition if "POSTPONE" is encountered by the
> text interpreter in the interpretation state (see 4.1.2 Ambiguous
> conditions), and nothing more.
>
> Any standard Forth system may define the custom interpretation semantics
> for POSTPONE (as well as for any other word without specified
> interpretation semantics). And a program may even rely on that, but such
> program probably is not a standard program.
>
> Any standard program may execute POSTPONE indirectly in the
> interpretation state. But actually it can execute its compilation
> semantics only. Therefore an ambiguous condition should exist if there
> is no current definition ("the definition whose compilation has been
> started but not yet ended") in this case.
>
>
> So, why don't to just redefine POSTPONE in the following way?
> : POSTPONE POSTPONE POSTPONE ; IMMEDIATE
>
> A standard program may do it. And after that this word may be correctly
> encountered by the text interpreter in the interpretation state.
>
> But the custom interpretation semantics of this word (if any) will be lost.
>
>
> --
> Ruvim

This is one of my disambiguifiers:
----------------------------------------------------------------------------
: postpone state @ 0= if cr ." WARNING: *** no interpretation semantics for: POSTPONE ***" cr then postpone postpone ; immediate
----------------------------------------------------------------------------

Good job, Ruvim!
You have just invented disambiguifiers!
Now Stephen Pelc will hate you too!

[hughag...@gmail.com]

On Sunday, July 21, 2019 at 8:52:59 PM UTC-7, hughag...@gmail.com wrote:
> On Thursday, July 18, 2019 at 10:04:53 AM UTC-7, Anton Ertl wrote:
> > I modified the code to avoid
> > Gforth-specific words:
> >
> > : (compile) ( -- ) r> dup cell+ >r @ compile, ;
> > : postpone ( "name" -- )
> > bl word find dup 0= abort" Can't compile "
> > 0> IF compile, ELSE postpone (compile) , THEN ;
> > immediate
> >
> > : POSTPONE-POSTPONE
> > POSTPONE POSTPONE ;
> >
> > : PPP1 123 ;
> > : PPP4 [ POSTPONE-POSTPONE PPP1 ] ; IMMEDIATE
> > : PPP5 PPP4 ;
> > PPP5 . \ prints 123
> >
> > and ran it (and the POSTPONE-POSTPONE test) on VFX and SwiftForth
> > (native-code systems). And they worked, too. Only iForth had a
> > problem with this code.
> >
> > Why does it work?
>
> It doesn't work. This is not ANS-Forth code!
> We have two blatant violations of ANS-Forth here:
>
> 1.) (COMPILE) is not ANS-Forth because section 3.2.3.3 says:
> "A program shall not access values on the return stack
> (using R@, R>, 2R@ or 2R>) that it did not place there using >R or 2>R;"
>
> 2.) It is illegal to put compiling words inside of [ ... ] brackets.
> All of the compiling words, such as POSTPONE COMPILE, etc., say:
> "Interpretation semantics for this word are undefined."
>
> Anton Ertl is well aware of both of these issues.
> Anton Ertl isn't making an honest mistake.
> Anton Ertl is a liar.

By far, the most bizarre blunder that Anton Ertl is making,
is to write POSTPONE in terms of FIND .
This doesn't work because FIND is broken in ANS-Forth.
Section 4.1.2 (Ambiguous Conditions) includes:
"attempting to obtain the execution token,
(e.g., with 6.1.0070 ', 6.1.1550 FIND, etc.) of a definition
with undefined interpretation semantics."
This means that FIND is not capable of finding words such as
IF ELSE THEN etc. (there are 50 some such words in ANS-Forth).

It is possible to fix FIND with the disambiguifiers.
For example:
---------------------------------------------------------------------
: if
state @ 0= if

cr ." WARNING: *** no interpretation semantics for: IF ***" cr
then
postpone if ;
immediate

---------------------------------------------------------------------
The disambiguifiers work because POSTPONE is not broken in ANS-Forth.
So, by hiding the problematic word (such as IF etc.) behind POSTPONE
the problem with FIND is dodged.
ANS-Forth is also ambiguous in that words such as IF are immediate
in some systems (SwiftForth) but are non-immediate in other systems (VFX).
The disambiguifiers get rid of this ambiguity by making all of these
words immediate, which is consistent with Forth-83.

The disambiguifiers only work if POSTPONE is not broken!
Obviously, it is impossible to define POSTPONE in terms of FIND though,
because the purpose of the disambiguifier is to fix the broken FIND .
Anton Ertl is well aware of this.
His code is not ANS-Forth and he knows it.

[hughag...@gmail.com]

On Tuesday, August 1, 2017 at 2:27:41 AM UTC-7, Stephen Pelc wrote:
> On Tue, 18 Jul 2017 21:28:18 -0700 (PDT), hughag...@gmail.com
> wrote:
>
> >My complaint against Stephen Pelc is that he uses dishonest business practi=
> >ces. He supports ANS-Forth and Forth-200x for the purpose of making all For=
> >th programmers look stupid. He doesn't actually use ANS-Forth himself. He r=
> >outinely provides vendor-specific code in VFX, even when it is easy to writ=
> >e the code in ANS-Forth, for the purpose of trapping his customers in vendo=
> >r lock-in. A good example is SYNONYM --- I can write this in ANS-Forth usin=
> >g my disambiguifiers --- he insists that this is impossible to write in ANS=
> >-Forth --- he refuses to admit that the disambiguifiers exist because he wa=
> >nts ANS-Forth's FIND to behave differently in every ANS-Forth compiler.
>
> Hugh's wonderful disambiguifiers do NOT do what the great Hugh thinks
> they do. What the great Hugh has done is to redefine a large number of
> words so that they behave in a very restricted way to support the
> great Hugh's version of Forth. Hugh's SYNONYM is not portable ANS
> Forth unless you use Hugh's Forth. Bah, humbug. Another emperor
> with no clothes.
>
> Stephen

Well, I look forward to seeing Stephen Pelc attack JennyB
for inventing the disambiguifiers
(possibly call her: "an empress with no clothes").

On Wednesday, July 24, 2019 at 6:22:27 PM UTC-7, hughag...@gmail.com wrote:
> On Wednesday, July 24, 2019 at 4:40:22 PM UTC-7, JennyB wrote:
> > Words with 'undefined interpretation semantics'
> > may be have either immediate or NCDS
> > compilation semantics. In the latter case,
> > their execution semantics are to perform a
> > useful system-dependent interpretation, or
> > simply to warn that they are compile-only.
> > Therefore, such words, in a Standard
> > program, may not be used inside a [ ... ]
> > block, or ticked and the xt executed.
> > This restriction is lifted when the word is
> > redefined thus:
> >
> > : foo postpone foo ; immediate
>
> Congratulations on inventing the disambiguifiers! Genius!
>
> I never claimed that the restriction of compiling words
> being used in [ ... ] brackets was lifted though.
> You're just lifting that restriction by fiat.
> Also, this restriction can't be lifted for most of the
> words with 'undefined interpretation semantics' such as
> R@ ABORT" DO CASE [CHAR] DOES> etc. (most of those words).
>
> I claimed that the disambiguifiers fix FIND to make it behave
> consistently and in a way that makes sense.
> The name "disambiguifier" means that the behavior of FIND
> is no longer ambiguous and no longer includes bizarre behavior
> such as aborting the system with a baffling error message.
>
> 1.) FIND obtains an xt for all of these words. Previously,
> FIND or tick of these words was an "ambiguous condition".
> The xt can be executed, but if you are in interpret mode
> then you get a warning message because this is not ANS-Forth.
>
> 2.) The xt obtained by FIND is the same whether FIND is
> executed in interpret or compile mode. Previously, the xt
> could be different depending upon STATE @ at the time that
> FIND is execute). Strictly speaking this bug in ANS-Forth
> isn't fixed because the ANS-Forth document says that FIND
> "may" return different xt values depending upon STATE @
> for any word. In practice though, this weirdity only occurs
> with these 'undefined interpretation semantics' words.
>
> 2.) FIND indicates that all of these words are immediate,
> which is consistent with Forth-83 and makes sense. Previously,
> these words were ambiguous; they might be non-immediate (VFX)
> or they might be immediate (SwiftForth) and the user had no
> way of finding out which they were except by testing for
> each ANS-Forth system.
>
> Note that I'm not lifting any restrictions by fiat,
> which is what JennyB is doing in Forth-200x.
> I'm just working around the bugs in ANS-Forth by using
> aspects of ANS-Forth that don't have bugs. Specifically,
> I'm working around the bugs in FIND by using POSTPONE
> that doesn't have any bugs. My disambiguifiers are
> ANS-Forth, so long as you don't claim that they lift any
> restrictions by fiat (specifically, saying they can be
> executed in [ ... ] brackets, which is still illegal).

[hughag...@gmail.com]

On Friday, August 16, 2019 at 2:17:09 PM UTC-7, Stephen Pelc wrote:
> On Fri, 16 Aug 2019 16:19:57 +0100, Alex McDonald <al...@rivadpm.com>
> wrote:
>
> >This is my understanding based on (a) not being there (b) being late to
> >Forth and (c) reading up on events and the technology from the distance
> >of 20+ years. And it wasn't my intention to speak for Stephen; it's my
> >interpretation of his post.
> >
> >Yes. Effectively because there are different results from words like
> >FIND based on STATE because of using different compilation and
> >interpretation wordlists to support non-standard compilation semantics;
> >and that accommodating it in the standard has left it with a number of
> >ugly gubbins and knobules.
>
> "Ugly gubbins and knobules" is a good summary. It was a bad idea at
> the time, and it's still a bad idea to allow FIND or its derivatives
> to be state-smart (IMHO). The whole point of an xt was to be a single
> point of reference to a word. SYNONYM messed up the one to one mapping
> between name and execution. Mea culpa. Then we introduced nts, which
> now seem to serve as the single point of reference to the dictionary
> header. As ever, some years after we introduce a new word, someone
> finds a case which makes the proposer regret the initial proposal.
>
> Stephen

Stephen Pelc considers himself to be the Emperor of Forth
and believes that only his mighty intellect is capable of
figuring out that it is a bad idea for FIND to return
different xt values depending upon STATE at the time FIND executes.
Stephen Pelc still hasn't invented disambiguifiers that fix
this in ANS-Forth though. He is introducing NTS that is Forth-200x.

Stephen Pelc and Alex McDonald remind me of Skipper and Gilligan.
They were endlessly trying to get off their island, and they
never admitted that it was their own fault for getting shipwrecked.

[Juergenstein Pelktaske]

Mr. Pelc went down in the Forth ranks after his
monster Pigta$ke lost the chain, stole his wallet
and rant the Forth Village with his public insults.

Juergenstein seems to be transplanted with a damaged brain
of a thief, because he does not stop to rob all free PDF
Forths and transform into Jef Bezzos bitcoins --> after beying
fired with all dishonour from MPE, he became
clerk of the month of Amazon <--

Alec Mc Donald also lost his way, and started imitating the hate speech
of claiming copyrigh on all free Forths documents,
as the real assistant of the monster Juergenstein...

All this freaks seems out of a terrible written
Forth-horror monster movie...

[dxforth]

On Saturday, 17 August 2019 11:19:50 UTC+10, hughag...@gmail.com wrote:
> ...

> Stephen Pelc and Alex McDonald remind me of Skipper and Gilligan.
> They were endlessly trying to get off their island, and they
> never admitted that it was their own fault for getting shipwrecked.

You're showing your age. While Jim Bachus' comedic roles have aged
(or perhaps it's just me) it was interesting to see him recently in an
old film noir 'A Dangerous Profession' 1949 playing a serious part.

[Jurgen Pitaske]

This arshole Peter Fucking Forth is active again - either drunk or his wife threw him out again, as usual. One of the most active Forth killers there is. Degarding this group to - YOU SELECT YOUR OWN NAME.

WARNING: WATCH OUT FOR IDENTITY THIEVES ON CLF https://www.facebook.com/peter.forth.583
In addition to just a copyright criminal, Peter Forsau is now stealing identities as well and posts whatever he feels like
In their name but - everybody can quite simply check this via the IP address where the post comes from.
Mental disturbance at its best, hopefully leading to walls around him soon.
As he hates the Forth Bookshelf I created so much, this link is probably the best verifier at the end of my posts
https://www.amazon.co.uk/Juergen-Pintaske/e/B00N8HVEZM

[Jurgen Pitaske]

And to make sure people can understand better what this idiot Peter Fart is so jealous about: It is my Forth Bookshelf, that I created on amazon over the last 7 years - as eBook and as print book for some:

I am quite proud about the bookshelf I generated and published.
A collection of Forth knowledge over the years.
With the most recent one actually the book I put together: A Start With Forth.
Starting with the ones written by Charles Moore – the inventor of Forth.
All with copyright for this publication.
It started with eBooks that I published and promoted – relatively low cost, worldwide delivery, download.
Many of them are now available as Print Books as well – easier to read and you can flick through them. The last print book I actually created as of a request in the Forth Facebook Group.
The current Forth Bookshelf can be found at
https://www.amazon.co.uk/Juergen-Pintaske/e/B00N8HVEZM
1 Charles Moore - Forth - The Early Years: Background information about the beginnings of this Computer Language
2P Charles Moore - Programming A Problem Oriented Language: Forth - how the internals work
3 Leo Brodie - Starting Forth -The Classic
4P Leo Wong – Juergen Pintaske – Stephen Pelc FORTH LITE TUTORIAL: Code tested with free MPE VFX Forth, SwiftForth and Gforth or else
5P Juergen Pintaske – A START WITH FORTH - Bits to Bites Collection – 12 Words to start, then 35 Words, Javascript Forth on the Web, more
6P Stephen Pelc - Programming Forth: Version July 2016
7P Brad Rodriguez - Moving Forth / TTL CPU / B.Y.O. Assembler
8P Tim Hentlass - Real Time Forth

9P Chen-Hanson Ting - Footsteps In An Empty Valley issue 3
10 Chen-Hanson Ting - Zen and the Forth Language: EFORTH for the MSP430G2552 from Texas Instruments
11 Chen-Hanson Ting - eForth and Zen - 3rd Edition 2017: with 32-bit 86eForth v5.2 for Visual Studio 2015
12 Chen-Hanson Ting - eForth Overview
13 Chen-Hanson Ting - FIG-Forth Manual Document /Test in 1802 IP
14 Chen-Hanson Ting - EP32 RISC Processor IP: Description and Implementation into FPGA – ASIC tested by NASA
15 Chen-Hanson Ting – Irriducible Complexity
16P Chen-Hanson Ting - Arduino controlled by eForth

17 Burkhard Kainka - Learning Programming with MyCo: Learning Programming easily - independent of a PC
18P Burkhard Kainka - BBC Micro:bit: Tests Tricks Secrets Code, Additional MicroBit information when running the Mecrisp Package
19 Burkhard Kainka – Thomas Baum – Web Programming ATYTINY13
20P Georg Heinrichs - The ATTINY Project
21P Prof. Dr. Karl Meinzer – IPS – A Forth-like Language for Space
22P PCN’s IchigoJam – A Japanese Educational Project. With BASIC now and FORTH to be added soon.

Is anybody interested in those “old” books? It seems there is …
Check it yourself in the top 100 here:
Best Sellers in Compiler Design
https://www.amazon.com/gp/bestsellers/books/3970/ref=pd_zg_hrsr_b_1_5_last#5
the last time I looked 08/08/2019:
1 Charles Moore - Forth - The Early Years: Background information about the beginnings of this Computer Language
( 55 ) 2P Charles Moore - Programming A Problem Oriented Language: Forth - how the internals work
3 Leo Brodie - Starting Forth -The Classic
4P Leo Wong – Juergen Pintaske – Stephen Pelc FORTH LITE TUTORIAL: Code tested with free MPE VFX Forth, SwiftForth and Gforth or else
( 80 ) 5P Juergen Pintaske – A START WITH FORTH - Bits to Bites Collection – 12 Words to start, then 35 Words, Javascript Forth on the Web, more
( 6 ) 6P Stephen Pelc - Programming Forth: Version July 2016
( 63 ) 7P Brad Rodriguez - Moving Forth / TTL CPU / B.Y.O. Assembler
8P Tim Hentlass - Real Time Forth

( 85 ) 9P Chen-Hanson Ting - Footsteps In An Empty Valley issue 3
10 Chen-Hanson Ting - Zen and the Forth Language: EFORTH for the MSP430G2552 from Texas Instruments
( 66 ) 11 Chen-Hanson Ting - eForth and Zen - 3rd Edition 2017: with 32-bit 86eForth v5.2 for Visual Studio 2015
( 94 ) 12 Chen-Hanson Ting - eForth Overview
( 71 ) 13 Chen-Hanson Ting - FIG-Forth Manual Document /Test in 1802 IP
14 Chen-Hanson Ting - EP32 RISC Processor IP: Description and Implementation into FPGA – ASIC tested by NASA
15 Chen-Hanson Ting – Irriducible Complexity
( 7 ) 16P Chen-Hanson Ting - Arduino controlled by eForth

17 Burkhard Kainka - Learning Programming with MyCo: Learning Programming easily - independent of a PC
18P Burkhard Kainka - BBC Micro:bit: Tests Tricks Secrets Code, Additional MicroBit information when running the Mecrisp Package
19 Burkhard Kainka – Thomas Baum – Web Programming ATYTINY13
( 93 ) 20P Georg Heinrichs - The ATTINY Project
21P Prof. Dr. Karl Meinzer – IPS – A Forth-like Language for Space

It changes day by day. And shows which of these books are ordered or read online.

[Rick C]

It's actually pretty hard to tell the two of you apart. You might do better ignoring him since it would only be half as bad if it were only him posting ugliness.

--

Rick C.

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

[hughag...@gmail.com]

On Monday, October 29, 2018 at 11:39:35 AM UTC-7, hughag...@gmail.com wrote:
> Here is another interesting quote:
>
> On Thursday, April 2, 2015 at 10:07:52 AM UTC-7, Stephen Pelc wrote:
> > On Wed, 1 Apr 2015 13:40:52 -0700 (PDT), hughag...@gmail.com
> > wrote:
> > >So how do you write SYNONYM so that it can make a synonym of an immediate word?
> >
> > The VFX source code is:
> >
> > : SynComp, \ xt --
> > \ Compile a child of SYNONYM.
> > >body @ compile,
> > ;
> >
> > : Synonym \ "<new-name>" "<curdef>" --
> > \ *G Create a new definition which redirects to an existing one.
> > \ ** Normal dictionary searches for *\i{<new-name>} will return
> > \ ** the xt of *\i{<curdef>}.
> > create
> > hide ' reveal dup , immediate?
> > if immediate endif
> > ['] SynComp, set-compiler
> > $010 latest set-bit \ set header's alias bit
> > interp>
> > @ execute
> > ;
> >
> > For some words you may have to RTFM.
> >
> > Stephen
>
> Cynical readers will notice that this code is not ANS-Forth. When Stephen Pelc (Forth-200x committee member) tells the plebian (Hugh Aguilar) to RTFM (Read The F'ing Manual), he is referring to the VFX manual. All of that code is VFX-specific. Stephen Pelc is trying to trap the VFX users into relying on vendor-specific code so they won't be able to port their code to competitor's ANS-Forth compilers --- vendor lock-in, of course, is what the standard is supposed to prevent!
>
> Alert readers will also notice this code has a bug in it. If SYNONYM is used to make a synonym of a word defined with CREATE and then >BODY is used on the synonym, >BODY will not return the body-address of the original word. I have read on comp.lang.forth that VFX has a new version that fixes this bug. I haven't bothered to download the new version however, so I haven't verified this. The more important problem is that Stephen Pelc is refusing to acknowledge the existence of the disambiguifiers and he is insisting that a word such as SYNONYM "requires carnal knowledge."
>
> On Thursday, April 2, 2015 at 11:42:55 PM UTC-7, Stephen Pelc wrote:
> > On Thu, 2 Apr 2015 19:18:04 -0700 (PDT), hughag...@gmail.com
> > wrote:
> > >This is not ANS-Forth code --- I don't want to RTFM because I don't want to
> > > become an expert on VFX --- I'm already an expert on ANS-Forth.
> >
> > You asked a tech-support question about VFX. I answered it pointing
> > out that your initial assumption (how IF works) was wrong.
> >
> > The code illustrates precisely why SYNONYM is defined the way it is
> > defined - because it requires carnal knowledge. If you want to know
> > how SYNONYM works:
> > "So how do you write SYNONYM so that it can make a synonym of an
> > immediate word?"
> > then do not complain when you are told.
> >
> > Stephen
>
> My assumption about IF was that it was immediate. This is sometimes right (SwiftForth) and sometimes wrong (VFX). The ambiguity of ANS-Forth, however, is meta-wrong --- ambiguity such as this is absurd --- ANS-Forth is a standard that doesn't standardize.
>
> Stephen Pelc is an extremely arrogant person! He is trying hard to say that I'm incompetent and that I need to learn basic Forth programming from him.
> He is incompetent and should learn from me! He does not deserve to be the Forth-200x chair-person!
>
> Anyway, my SYNONYM SYNONYM-FAST and ALIAS are all ANS-Forth and they all support immediate words. They depend upon the disambiguifiers to work:
> -----------------------------------------------------------------------
> : oink postpone if ; immediate ok
> : test oink ." true" else ." false" then ; ok
> 1 test true ok
> 0 test false ok
> get-current alias oinkA oink ok
> : testA oinkA ." true" else ." false" then ; ok
> 1 testA true ok
> 0 testA false ok
> get-current synonym oinkS oink ok
> : testS oinkS ." true" else ." false" then ; ok
> 1 testS true ok
> 0 testS false ok
> get-current synonym-fast oinkFS oink ok
> : testFS oinkFS ." true" else ." false" then ; ok
> 1 testFS true ok
> 0 testFS false ok
> -----------------------------------------------------------------------
>
> Also, ALIAS supports >BODY correctly, which Stephen Pelc's non-standard code shown above failed to support:
> -----------------------------------------------------------------------
> create foo 1234 , ok
> get-current alias bar foo ok
> foo @ . 1234 ok
> bar @ . 1234 ok
> ' foo >body @ . 1234 ok
> ' bar >body @ . 1234 ok
> foo . 5167168 ok
> bar . 5167168 ok
> ok
> 5678 foo ! ok
> foo @ . 5678 ok
> bar @ . 5678 ok
> ' foo >body @ . 5678 ok
> ' bar >body @ . 5678 ok
> -----------------------------------------------------------------------

Stephen Pelc still doesn't know how to write SYNONYM in ANS-Forth!
He says:

On Wednesday, September 18, 2019 at 12:31:34 PM UTC-7, Stephen Pelc wrote:
> On Tue, 17 Sep 2019 12:16:40 -0700 (PDT), m...@iae.nl wrote:
>
> >I'll bite. Why do I want SYNONYM, and what are those interesting new
> >features" ?
>
> I want SYNONYM when a porting code that uses WORD1 when the same
> behaviour is provided in my system by WORD2.
> SYNONYM WORD1 WORD2
>
> That's all. I regret that SYNONYM lead to nts and so on. Mea culpa.
> As always, be careful what you wish for.
>
> Stephen

Here is the ANS-Forth code (that depends upon having disambiguifiers
already loaded). There are no NTs and so on.
--------------------------------------------------------------------
\ ******
\ ****** Our SYNONYM SYNONYM-FAST and ALIAS words --- these depend upon having the disambiguifiers available.
\ ******

: :synonym { xt flg str wid -- } \ FLG is 1 for immediate and -1 for non-immediate
str wid :name
flg 1 = if xt lit, execute, ;, immediate exit then
flg -1 = if xt compile, ;, exit then
true abort" *** :SYNONYM given an invalid xt ***" ;

: :synonym-fast-check ( -- )
state @ 0= abort" *** a word created by :SYNONYM-FAST can't be used in interpretive mode ***" ;

: :synonym-fast { xt flg str wid -- } \ FLG is 1 for immediate and -1 for non-immediate
str wid :name
flg 1 = if xt lit, execute, ;, immediate exit then
flg -1 = if postpone :synonym-fast-check
xt lit, postpone compile, ;, immediate exit then
true abort" *** :SYNONYM-FAST given an invalid xt ***" ;

: 'find ( -- xt flg ) \ stream: name \ FLG is 1 for immediate and -1 for non-immediate
bl word find dup 0= abort" *** 'FIND couldn't find the word ***" ;

: synonym { wid | new -- } \ stream: new-name old-name \ the new word is compiled into the WID word-list
bl word hstr to new
'find new wid :synonym
new dealloc ;

: synonym-fast { wid | new -- } \ stream: new-name old-name \ the new word is compiled into the WID word-list
bl parse <hstr> to new
'find new wid :synonym-fast
new dealloc ;

\ :SYNONYM-FAST generates faster executing code than :SYNONYM but the words can't be used in interpretive mode.
\ This may not be necessary with a good optimizing compiler, but I'm not aware of any at this time.

1234512345 constant alias-id \ an arbitrary number used to identify alias'd definitions

0
w field alias.xt \ this should be the first field so the DOES> portion of ALIAS will be fast (no addition needed)
w field alias.adr \ the address of the body, used to identify alias'd definitions
w field alias.id \ the constant ALIAS-ID, used to identify alias'd definitions
constant alias-struct

: alias ( wid -- ) \ stream: new-name old-name \ the new word is compiled into the WID word-list
get-current swap set-current create set-current
here >r alias-struct allot
'find 1 = if immediate then r@ alias.xt !
r@ r@ alias.adr !
alias-id r@ alias.id !
rdrop
does>
alias.xt @ execute ;

\ ALIAS does the same thing as SYNONYM but has the advantage that ' ['] and >BODY will work on it.
\ It is slower executing though (especially under SwiftForth in which CREATE DOES> words are very inefficient).

: ' ( -- xt ) \ stream: name
' \ -- xt
dup >body >r
r@ alias.adr @ r@ = if r@ alias.id @ alias-id = if \ is this an alias'd word?
drop r> alias.xt @ exit then then \ return the xt of the original word
rdrop ;

: ['] ( -- ) \ stream: name \ runtime: -- xt
' postpone literal ; immediate

: >body ( xt -- adr )
>body >r
r@ alias.adr @ r@ = if r@ alias.id @ alias-id = if \ is this an alias'd word?
r> alias.xt @ >body exit then then \ return the body of the original word
r> ; \ return the body of this word

\ Note that >BODY still has an undefined result if used on a word that wasn't defined with CREATE or isn't an alias of such a word.

: special-macro: ( xt -- xt | 0 ) \ returns 0 if xt was special-cased
[ 'special-macro: @ ] literal execute dup 0= if exit then
case

['] ['] of postpone ['] postpone lit, 0 exit endof

exit endcase ; \ -- xt \ EXIT with xt if it was never special-cased

' special-macro: 'special-macro: !

\ We need to upgrade SPECIAL-MACRO: with our new ['] because the old one isn't valid anymore.
--------------------------------------------------------------------

On a related note, these quotes come from VFX's "tip of the day"
--------------------------------------------------------------------
"Never attribute to malice that which can be explained by stupidity."
Hanlon's Razor

"Stupidity maintained long enough is a form of malice."
Richard Bos's corollary to Hanlon's Razor.
--------------------------------------------------------------------

[dxforth]

On Friday, 20 September 2019 07:29:58 UTC+10, hughag...@gmail.com wrote:
> > ...

> > Alert readers will also notice this code has a bug in it. If SYNONYM is used to make a synonym of a word defined with CREATE and then >BODY is used on the synonym, >BODY will not return the body-address of the original word.

Swiftforth's AKA manages to get away with that 'bug' and more.

> > I have read on comp.lang.forth that VFX has a new version that fixes this bug. I haven't bothered to download the new version however, so I haven't verified this.

VFX Forth for Windows IA32
© MicroProcessor Engineering Ltd, 1998-2017

Version: 4.80 [build 3621]
Build date: 27 June 2017

Free dictionary = 7510606 bytes [7334kb]

create foo ok
synonym bar foo ok
' foo >body ' bar >body - . 0 ok

>
> On a related note, these quotes come from VFX's "tip of the day"
> --------------------------------------------------------------------
> "Never attribute to malice that which can be explained by stupidity."
> Hanlon's Razor
>
> "Stupidity maintained long enough is a form of malice."
> Richard Bos's corollary to Hanlon's Razor.
> --------------------------------------------------------------------

"Self-righteousness maintained long enough is stupidity."

completes the loop

[hughag...@gmail.com]

It is better to be righteous than wrongeous!

[hughag...@gmail.com]

On Friday, March 22, 2019 at 9:16:05 PM UTC-7, hughag...@gmail.com wrote:
> Certainly the only virtue of ]] ... [[ is that Anton Ertl used a goofy
> contorted technique to avoid using FIND that is ambiguous.
> He didn't use FIND because doing so would have offended Elizabeth Rather
> and Stephen Pelc (because they hate the needed disambiguifiers).
> Elizabeth Rather screwed up FIND in 1994 and now, in 2019, her disgusting
> sycophant Anton Ertl is striving mightily to avoid mentioning that
> FIND is ambiguous, and he is avoiding fixing FIND with the disambiguifiers.
> Of course, Anton Ertl's code is crap.
> His ]] ... [[ fails badly because it doesn't support immediate words
> such as ['] [CHAR] POSTPONE ." etc. that remove data from the input stream.
> My POST: does support all of these words, which is easy to do.
> (note that I originally called it INLINE: but then switched to POST:
> that may be somewhat more readable).
> POST: is used internally by MACRO: that I use quite a lot.

I this thread:
https://groups.google.com/forum/#!topic/comp.lang.forth/1SDLacsZprk

We have Ruvim admitting that Anton Ertl's ]] fails badly:

On Wednesday, February 19, 2020 at 6:29:58 PM UTC-7, Ruvim wrote:
> From a user point of view, the idea of the "]] ... [[" construct is
> that you can wrap by it some fragment of code as is and this fragment
> will be postponed (i.e. the execution semantics of this fragment will be
> appended to the current definition on execution of the surrounded
> fragment). I.e., this construction looks like it supports
> copy-pasteability. But this sense is fallacious. Actually, in this
> variant, this construction will not support copy-pastebility in many cases.
>
> So, the POSTPONE-based approach is quite simple, but it is error-prone
> and misleading, since it breaks copy-pasteability in the certain cases.
> Actually, all the words that have parsing in compilation semantics are
> affected by this issue. (*)

Now all we need is for Ruvim to admit that my POST: and MACRO:
(based on the disambiguifiers) works in exactly the cases that
he has already admitted that ]] fails on.

[Hugh Aguilar]

Here is another thread with Ruvim in it:
https://groups.google.com/g/comp.lang.forth/c/JU-Xbqfdeg0

On Friday, June 11, 2021 at 11:55:40 AM UTC-7, Ruvim wrote:
> On 2021-06-11 12:57, Anton Ertl wrote:
> > Ruvim <ruvim...@gmail.com> writes:
> >> On 2021-06-10 18:49, Anton Ertl wrote:
> >>> As Ruvim notes, the standard undefines interpretation semantics for
> >>> words that deal with the return stack, and as a consequence a standard
> >>> program cannot tick or FIND these words.
> >>
> >> More neatly, a standard program cannot use "FIND" to obtain the
> >> execution token of such a word.
> >>
> >> But it can use "FIND" to obtain xt of a definition that serves to
> >> perform the interpretation or compilation semantics for such a word.
> >
> > If one of our "Clarify FIND" proposals is accepted, yes. But in
> > Forth-94 and Forth-2012, it's an ambiguous condition:
> >
> > |4.1.2 Ambiguous conditions

> > |
> > |attempting to obtain the execution token, (e.g., with 6.1.0070 ',

> > |6.1.1550 FIND, etc. of a definition with undefined interpretation
> > |semantics;
> Well, but "FIND" may be applied to any string, isn't it?
>
> So, if a program applies "FIND" to some string, does it mean that the
> program attempts to obtain the execution token of the corresponding
> named definition? (1)
>
> A problem is that the spec says that "FIND" returns "its execution
> token", i.e. the execution token *of* the found definition. Also it says
> that "FIND" may return the different values depending on state. In this
> context, the different xt means that they identify the different ES. But
> a definition may have not more than one ES. Hence, the specification for
> "FIND" contradicts itself.
>
> The parts "its execution token" and "the values [...] may differ" are
> mutually exclusive. If one of them is true, another is false.
>
> From a contradict formula, one can infer both some proposition and its
> negation. So the answer to the question (1) cannot rely on the
> contradict specification for "FIND".

That is hilarious! Ruvim has figured out that ANS-Forth is self-contradictory
in regard to FIND --- I have been saying this for quite some time! --- if you can
infer both a proposition and its negation, then you are in trouble (just press
the flush lever and dispose of ANS-Forth finally, as the smell of Elizabeth Rather's
incompetence is becoming awful enough that perfume doesn't work anymore).

As usual, Anton Ertl blathers on about how using FIND on a word such as I
is an "ambiguous condition." With the disambiguifiers this is not ambiguous
though. You always get an xt of an immediate word (the flag indicates immediacy).

This thread came about because of this:

On Thursday, June 10, 2021 at 5:36:26 AM UTC-7, Krishna Myneni wrote:
> : test ['] I 10 0 do dup execute . loop drop cr ;

Given the disambiguifiers, I is always an immediate word.
This isn't ambiguous --- the code just has a bug in that it is trying to execute
an immediate word at run-time --- the question is not, as Krishna Myneni supposed,
whether or not EXECUTE holds data on the return-stack, because that is
irrelevant due to the fact that immediate words can't be executed at run-time anyway.

You can't have a non-immediate word that modifies the return-stack because
this violates the rule that R> can only access data that it put on the return-stack
with >R earlier. Words like I >R R> etc. have to be immediate, which the
disambiguifiers conveniently guarantee unambiguously!

[Hugh Aguilar]

On Monday, January 1, 2018 at 5:24:35 PM UTC-7, hughag...@gmail.com wrote:
> On Tuesday, August 1, 2017 at 2:27:41 AM UTC-7, Stephen Pelc wrote:
> > On Tue, 18 Jul 2017 21:28:18 -0700 (PDT), hughag...@gmail.com
> > wrote:
> >
> > >My complaint against Stephen Pelc is that he uses dishonest business practi=
> > >ces. He supports ANS-Forth and Forth-200x for the purpose of making all For=
> > >th programmers look stupid. He doesn't actually use ANS-Forth himself. He r=
> > >outinely provides vendor-specific code in VFX, even when it is easy to writ=
> > >e the code in ANS-Forth, for the purpose of trapping his customers in vendo=
> > >r lock-in. A good example is SYNONYM --- I can write this in ANS-Forth usin=
> > >g my disambiguifiers --- he insists that this is impossible to write in ANS=
> > >-Forth --- he refuses to admit that the disambiguifiers exist because he wa=
> > >nts ANS-Forth's FIND to behave differently in every ANS-Forth compiler.
> >
> > Hugh's wonderful disambiguifiers do NOT do what the great Hugh thinks
> > they do. What the great Hugh has done is to redefine a large number of
> > words so that they behave in a very restricted way to support the
> > great Hugh's version of Forth. Hugh's SYNONYM is not portable ANS
> > Forth unless you use Hugh's Forth. Bah, humbug. Another emperor
> > with no clothes.
> >
> > Stephen

Stephen Pelc is now lying about lying:

On Monday, January 3, 2022 at 6:27:11 AM UTC-7, Stephen Pelc wrote:
> On 3 Jan 2022 at 03:03:03 CET, Mr Angry, "Hugh Aguilar"
> <hughag...@gmail.com> wrote:
>
> > Stephen Pelc says that my disambiguifiers don't work, although he doesn't have
> > either
> > SYNONYM or and early-binding MACRO: which both depend upon the disambiguifiers.
> > Stephen Pelc says that anybody can write a better string-stack that what I
> > have,
> > although he has nothing to show, and this has been about 30 years now.
> Lies, lies, lies.

[Jurgen Pitaske]

You dug yourself a hole again - welcome to 2022.

5 Years ago you complain about MPE stating that your dihonestifiers do not do what you say.
You complain again now after 5 years
- without proving MPE was then or even is now wrong after you might have adapted it.
What sort of unprofessional behaviour is this?

MPEs products and services are appreciated as MPE is a company for many many years - and successfully.
You are telling the world you are the God of Forth - but nobody wants your Forth programming services it seems.
Which companies / projects have you worked for showing your Forth competance over the last 10 years?
HHHHHHM...

[Hugh Aguilar]

On Monday, January 1, 2018 at 5:24:35 PM UTC-7, hughag...@gmail.com wrote:

> For a long time I believed that the above problems with FIND made ANS-Forth unusable.
> Then I remembered the disambiguifiers that Anton Ertl invented:

>
> : if state @ 0= if cr ." WARNING: *** no interpretation semantics for: IF ***" cr then
> postpone if ; immediate
>

> This fixes all of the problems with FIND listed above!
> The disambiguifiers are the heart and soul of ANS-Forth programming!
>
> Section 4.1.2 said that an ambiguous condition is:
> "attempting to obtain the execution token, (e.g., with 6.1.0070 ', 6.1.1550 FIND, etc.)
> of a definition with undefined interpretation semantics."
> We are no longer attempting this however, because now we are using FIND
> to obtain the xt of a user-written word (the disambiguifier).

Stephen Pelc lied when he said that the disambiguifiers don't work.
Now Stephen Pelc has his sycophant Hans Bezemer desperately claiming
that ANS-Forth's statement that FIND and tick behavior being undefined for
51 words in ANS-Forth is: "the end of the line." This is from:
https://groups.google.com/g/comp.lang.forth/c/hp1MbSkew08

On Thursday, February 9, 2023 at 8:40:04 AM UTC-7, Hans Bezemer wrote:
> On Wednesday, February 8, 2023 at 8:42:14 PM UTC+1, Hugh Aguilar wrote:
> > Stephen Pelc totally lied when he said that the disambiguifiers don't work.
> > The disambiguifiers fix the bug in ANS-Forth that makes FIND and tick ambiguous
> > and unusable on all of the words in ANS-Forth (51 of them) whose definition includes
> > the statement: "Interpretation semantics for this word are undefined."
> > https://groups.google.com/g/comp.lang.forth/c/T-yYkpVwYew/m/tNE4Q9aNDwAJ
> Well, if the standards state "Interpretation semantics for this word are undefined" then
> that's the end of the line. You state yourself that's due to "a bug in ANS Forth". Hence,
> if a compiler is ANS compliant, it will contain that "bug". So what is exactly bugging you:
> the "bug" in ANS or the "bug" in VFX "not conforming to ANS. I lost track.

Hans is lying! This is not the: "end of the line."
The truth is that the disambiguifiers work around this bug in ANS-Forth.

Hans attempts to weasel out of this lie by saying that he "lost track" of what
the discussion is about. No he didn't! He never understood what the discussion
was about. He doesn't know what disambiguifiers are. He doesn't care,
because he just wants to blindly support Stephen Pelc without any regard
for the truth or with any knowledge of ANS-Forth. Hans Bezemer is in the same
category as Juergen Pintaske --- his loyalty is equaled only by his ignorance.

Back in 1994, UR/Forth from LMI was the premier professional Forth system.
The purpose of ANS-Forth was to kill UR/Forth by declaring it by fiat to be
non-standard. In those days, MPE was one minor competitor to Forth Inc.,
along with several other minor competitors. None of them were competitive
with UR/Forth. All of the minor competitors to Forth Inc. were killed off
by ANS-Forth except for MPE that survived and is now dominant.
Why did MPE survive?
I think that Stephen Pelc made a deal with Elizabeth Rather that she would
not kill MPE off by declaring his Forth system to be non-standard, but she
would allow MPE to be standard. In exchange, Stephen Pelc would write
Forth code for Forth Inc. --- Elizabeth Rather needed somebody to write
Forth code for Forth Inc. because Forth Inc. employed only salesmen.
Forth Inc. is great at selling, primarily because the name "Forth Inc." implies
that they are the flagship of the Forth community, and because they can
endlessly remind everybody that Charles Moore founded Forth inc.
(neglecting to mention that Charles Moore got kicked out of Forth Inc. in 1982).
Elizabeth Rather is a marketing genius!
She is not a Forth programmer though, and she doesn't employ any Forth
programmers because no self-respecting Forth programmer can make it
through her novice class without laughing out loud at her ignorance of Forth.
After ANS-Forth killed Forth, most of the Forth community just gave up
on Forth and switched to C programming. I didn't, because I was employed
at Testra as a Forth programmer when Forth died, but after I left Testra
I did give up on Forth programming for a long time because Forth was dead.

Stephen Pelc made a Faustian Bargain. He was allowed to survive, but
he had to sell his soul to Elizabeth Rather. Now, decades later, Stephen Pelc
is still desperately trying to say that ANS-Forth was viable from a technical
standpoint. He can't admit that the disambiguifiers fix the problem in
ANS-Forth of FIND and tick not working, because admitting this would also
require him to admit that ANS-Forth was so stupidly designed that FIND and tick
don't work. FIND and tick are actually pretty basic Forth that worked just fine
in Forth-83. UR/Forth etc. had FIND and tick working. ANS-Forth's failure
to get this basic Forth concept working indicates gross incompetence on
the part of Elizabeth Rather and all of her sycophants on the ANS-Forth committee.
Stephen Pelc can't tell the truth because he sold his soul and is required to lie.

[dxforth]

On 11/02/2023 12:31 pm, Hugh Aguilar wrote:
> ...

> Forth Inc. is great at selling, primarily because the name "Forth Inc." implies
> that they are the flagship of the Forth community, and because they can
> endlessly remind everybody that Charles Moore founded Forth inc.
> (neglecting to mention that Charles Moore got kicked out of Forth Inc. in 1982).
> Elizabeth Rather is a marketing genius!

> ...

> Stephen Pelc made a Faustian Bargain. He was allowed to survive, but
> he had to sell his soul to Elizabeth Rather.

COVID conspirators need only look to Forth for fun and inspiration. Moore is
part of the Faustian pact - he can keep his reputation by saying he left out of
boredom rather than being kicked out. Same when he was booted from ANS. He
wasn't permitted to create a Standard in opposition and had to stick to the
line he doesn't believe in standards.

Hugh, we make a great team. Nobody suspects we're in this together.

[Jurgen Pitaske]

WELCOME TO THE LEADER OF FORTH 2020 - PETER WHOEVER -
OR IS DICTATOR OF FORTH 2020 A BETTER WORD ???????