On 12/06/2021 00:47, gobli...@gmail.com wrote:
> Hi there,
>
> To improve my skill, practice is one of the keys, so what can I find as good books & reference books ?
>
> Because website are nearly all for beginners or expert but transition is quite hard between both
>
> Please say title, author if known, maybe publication date, free or not , is it electronic version or may I find it as physical one ?
>
> Currently, I use nearly only Gnu forht & fig forth ; but I use it unoptimized way.
>
> I guess also old 8bits computer generations forth books may help ? Right ?
>
> regards.
>
>
> (if there are already a list in this google-group you can give me the link, but I failed to find one)
>

When you've got all you can from books, I suggest looking at complete
applications. Rather than disparate snippets of code, you'll get to
see how all the components cleanly fit together. None of this happens
automatically or by design - rather the result of several iterations.
You may not understand it but will show the quality of code to aim for
in your own projects.

On Friday, June 11, 2021 at 11:06:19 PM UTC-7, dxforth wrote:
> On 12/06/2021 00:47, gobli...@gmail.com wrote:
> > Hi there,
> >
> > To improve my skill, practice is one of the keys, so what can I find as good books & reference books ?
> >
> > Because website are nearly all for beginners or expert but transition is quite hard between both
> >
> > Please say title, author if known, maybe publication date, free or not , is it electronic version or may I find it as physical one ?
> >
> > Currently, I use nearly only Gnu forht & fig forth ; but I use it unoptimized way.
> >
> > I guess also old 8bits computer generations forth books may help ? Right ?
> >
> > regards.
> >
> >
> > (if there are already a list in this google-group you can give me the link, but I failed to find one)
> >
> When you've got all you can from books, I suggest looking at complete
> applications. Rather than disparate snippets of code, you'll get to
> see how all the components cleanly fit together. None of this happens
> automatically or by design - rather the result of several iterations.
> You may not understand it but will show the quality of code to aim for
> in your own projects.

Bullshit!
DXforth is offering you the path to becoming a maintenance programmer --- nobody has respect for
maintenance programmers though --- they are parasites and carrion-eaters.

The only way to learn programming is by programming.
I gave the OP a list of homework assignments to start on:
https://groups.google.com/g/comp.lang.forth/c/IAD_5btla4A
On Tuesday, June 8, 2021 at 5:22:18 PM UTC-7, Hugh Aguilar wrote:
> In my novice package I have these easy programs:
> * parallel-resistance calculator
> * fizz-buzz (classic job-interview question)
> These are slightly harder:
> * Towers of Hanoi
> * currency change-making (actually is useful)
> This is slightly harder:
> * Nqueens

In your day-of-week calculator you were doing your own input. This is not really
typical in Forth because you have an outer-interpreter.
For example, this is my parallel resistance calculator:
: par ( r1 r2 -- r ) \ parallel resistance
2dup + */ ;
Notice how this is robust. If you have 3 resistors, do this:
par par

The rule for FizzBuzz is to iterate through numbers from 1 to 100 and print the number
unless it is a divisible by 3 in which case you print 'fizz' or divisible by 5 in which case
you print 'buzz' (you print 'fizz buzz' if it is divisible by 15.
Here is Gerry Jackson's attempt:
------------------------------------------------------------------------------
hex
1249 constant fizzers \ Bits 3i set, i = 0 to 4
0421 constant buzzers \ Bits 5i set, i = 0 to 2
4000 constant reset-probe \ Bit 14 set
decimal

: fizzbuzz
cr 0 101 1
do
?dup 0= if reset-probe then ( -- probe )
[ fizzers buzzers or ] literal over and 0= if i . then
fizzers over and if ." fizz" then
buzzers over and if ." buzz" then
1 rshift cr ( -- probe' )
loop drop
;
------------------------------------------------------------------------------
This is bad programming because it is not robust.
The interviewer could ask: "Okay, now upgrade the program to print 'burp' on multiples of 7."
This requires going from a bit-mask of 15 bits to 105 bits. Ruh roh!
As a novice Forther, you should be able to write a more robust program that can be
upgraded easily as I have described. Try it!

As a rule of thumb, if you can program better than the Forth-200x committee
every time in every way, then you have graduated from novice to intermediate level Forth.

Hugh Aguilar <hughaguilar96@gmail.com> wrote:

> Bullshit!

As he does most of the time.

> For example, this is my parallel resistance calculator:
> : par ( r1 r2 -- r ) \ parallel resistance
> 2dup + */ ;
> Notice how this is robust.

LOL - until you have 2 resistors with 0 ohms: then this code fails and
aborts. (In the "novice package" it goes on just as sloppy with a
program for n resistors being just as robust)

That's Hugo-robust, not "robust"-robust.

> The rule for FizzBuzz is to iterate through numbers from 1 to 100 and print
> the number
> unless it is a divisible by 3 in which case you print 'fizz' or divisible by
> 5 in which case
> you print 'buzz' (you print 'fizz buzz' if it is divisible by 15.

Look i broke the lines for you.

....

> The interviewer could ask: "Okay, now upgrade the program to print 'burp' on
> multiples of 7."

The interviewer could ask a lot when the day is long.

> As a rule of thumb, if you can program better than the Forth-200x committee
> every time in every way, then you have graduated from novice to intermediate
> level Forth.

Bla bla blech!

On Sunday, June 13, 2021 at 12:45:06 AM UTC-7, Alexander Wegel wrote:
> Hugh Aguilar <hughag...@gmail.com> wrote:
>
> > Bullshit!
>
> As he does most of the time.
> > For example, this is my parallel resistance calculator:
> > : par ( r1 r2 -- r ) \ parallel resistance
> > 2dup + */ ;
> > Notice how this is robust.
> LOL - until you have 2 resistors with 0 ohms: then this code fails and
> aborts. (In the "novice package" it goes on just as sloppy with a
> program for n resistors being just as robust)
>
> That's Hugo-robust, not "robust"-robust.

Alex Wegel doesn't know what the word "robust" means.
The word "robust" in regard to software means that the software can be
modified easily to accommodate changing requirements and/or
additional requirements (such as adding 7 to the special numbers in fizz-buzz).

The word "robust" does not mean doing nit-picking error-checking looking for
unlikely input values, such as checking for a resistor value of zero (I really doubt
that the user will be working with super-conductors that have zero resistance).

Alex Wegel doesn't know basic terminology, such as the word: "robust."
He is a novice-level Forth programmer. His ego prevents him from learning,
so he will never improve --- he is always lecturing me on subjects that he
is ignorant of --- he is an irksome troll who can't program.

A good example of non-robust code is in this thread:
https://groups.google.com/g/comp.lang.forth/c/HwxAddZ54mg/m/-Miq-hqQAQAJ

On Wednesday, June 17, 2020 at 12:05:23 AM UTC-7, hughag...@gmail.com wrote:
> As I have said many times in the past, the bucket-sort only works when
> the values are within a small range. The bucket-sort fails when the
> values are in a wide range that is too big for an array of buckets.
> This is why Michael Gassanenko's algorithm is no good for a sparse set
> of selector values --- their range is too big for an array of buckets.

Michael Gassanenko's CHOOSE (switch) code was not robust. He succeeded
in getting the jump-table working, comparable to my FAST-SWITCH> but he did not
succeed in getting a sparse jump-table working because he used a bucket-sort
that is restricted to a small range of values, whereas I used a linked-list that could
support a wide range of values, so writing SLOW-SWITCH> after I had written
FAST-SWITCH> was an easy upgrade. Robust design makes for easy upgrades.

This thread is also a good example of a maintenance programmer (Gerry Jackson)
making a complete fool out of himself. Gerry stole Gassanenko's code and put
his own copyright on it. Gerry then said this:

On Wednesday, June 10, 2020 at 2:34:55 PM UTC-7, Gerry Jackson wrote:
> As in MLG's implementation the switch selectors are accumlated on the
> stack and processed when the final END is reached.
> ...
> At some stage I'll probably add two alternative versions, one for a
> sparse set of selectors using a binary search or hashing, ...

Gerry Jackson obviously doesn't understand how the code of Michael Gassanenko (MLG)
works --- he doesn't know about the problem of MLG using the wrong sort algorithm.
Because of this, the "stage" where Gerry writes something comparable to my SLOW-SWITCH>
that supports a sparse set of selectors has never arrived.
This is very typical of maintenance programmers. They claim to be instant experts on somebody's
code, but they don't understand how the code works --- they never succeed at anything.

Hugh Aguilar <hughaguilar96@gmail.com> wrote

...nothing worth mentioning, unless someone insists.

At least the OP should be warned by now.

In article <1parhvf.us999e1uo9aydN%awegel@arcor.de>,
Alexander Wegel <awegel@arcor.de> wrote:
>Hugh Aguilar <hughaguilar96@gmail.com> wrote
>
>..nothing worth mentioning, unless someone insists.
>
>At least the OP should be warned by now.

sed -e s/disambiguators/stolen/

Hugh's rants gives me the same feeling as Don's.
Maybe it is time to pull the plug.

Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

On 14/06/2021 03:06, Hugh Aguilar wrote:
> On Sunday, June 13, 2021 at 12:45:06 AM UTC-7, Alexander Wegel wrote:
>> Hugh Aguilar <hughag...@gmail.com> wrote:
>>
>>> Bullshit!
>>
>> As he does most of the time.
>>> For example, this is my parallel resistance calculator:
>>> : par ( r1 r2 -- r ) \ parallel resistance
>>> 2dup + */ ;
>>> Notice how this is robust.
>> LOL - until you have 2 resistors with 0 ohms: then this code fails and
>> aborts. (In the "novice package" it goes on just as sloppy with a
>> program for n resistors being just as robust)
>>
>> That's Hugo-robust, not "robust"-robust.
>
> Alex Wegel doesn't know what the word "robust" means.
> The word "robust" in regard to software means that the software can be
> modified easily to accommodate changing requirements and/or
> additional requirements (such as adding 7 to the special numbers in fizz-buzz).
>
> The word "robust" does not mean doing nit-picking error-checking looking for
> unlikely input values, such as checking for a resistor value of zero (I really doubt
> that the user will be working with super-conductors that have zero resistance).
>
> Alex Wegel doesn't know basic terminology, such as the word: "robust."
> He is a novice-level Forth programmer. His ego prevents him from learning,
> so he will never improve --- he is always lecturing me on subjects that he
> is ignorant of --- he is an irksome troll who can't program.
>
> A good example of non-robust code is in this thread:
> https://groups.google.com/g/comp.lang.forth/c/HwxAddZ54mg/m/-Miq-hqQAQAJ
>
> On Wednesday, June 17, 2020 at 12:05:23 AM UTC-7, hughag...@gmail.com wrote:
>> As I have said many times in the past, the bucket-sort only works when
>> the values are within a small range. The bucket-sort fails when the
>> values are in a wide range that is too big for an array of buckets.
>> This is why Michael Gassanenko's algorithm is no good for a sparse set
>> of selector values --- their range is too big for an array of buckets.
>

Sigh, so many lies and much abuse. Normally I now ignore your posts but
as you make a libellous statement about me this is to put the record
straight and to show newbies what a gobshite you are.

> Michael Gassanenko's CHOOSE (switch) code was not robust. He succeeded
> in getting the jump-table working, comparable to my FAST-SWITCH> but he did not
> succeed in getting a sparse jump-table working because he used a bucket-sort
> that is restricted to a small range of values,

Wrong Michael Gassanenko (MLG) does no explicit sorting, you don't
understand what he's done. Also how can you say he did not succeed at
something when you have no evidence he actually tried.

MLG states it's not suitable for a sparse set of values.

> whereas I used a linked-list

He suggests using a tree based structure that would be faster than a
linked list

> that could
> support a wide range of values, so writing SLOW-SWITCH> after I had written
> FAST-SWITCH> was an easy upgrade. Robust design makes for easy upgrades.
>
> This thread is also a good example of a maintenance programmer (Gerry Jackson)

Wrong, you're the fool, I've never worked as a maintenance programmer.

> making a complete fool out of himself.

Gratuitous insult time again by a malicious troll

> Gerry stole Gassanenko's code and put > his own copyright on it.

Wrong, that's a libel and can easily be disproved by looking at the
source code of Michael Gassanenko and mine at:
https://github.com/gerryjackson/Forth-switch

Gerry then said this:
>
> On Wednesday, June 10, 2020 at 2:34:55 PM UTC-7, Gerry Jackson wrote:
>> As in MLG's implementation the switch selectors are accumlated on the
>> stack and processed when the final END is reached.

But MLG puts them as a linked list whereas I have a sequence of
subsequences which is easier to process

>> ...
>> At some stage I'll probably add two alternative versions, one for a
>> sparse set of selectors using a binary search or hashing, ...
>
> Gerry Jackson obviously doesn't understand how the code of Michael Gassanenko (MLG)
> works

Wrong, I do understand it, you obviously don't because you clearly
haven't read either his solution or mine. MLG's solution used return
stack manipulation (RSM) extensively which is non-standard Forth. My
solution uses standard Forth and not RSM which means the code is
fundamentally different.

That means you don't understand RSM which also proves you stole
Hunpty-Dumpty's code for rquotations which Humpty-Dumpty in turn
(probably inadvertently) re-purposed some RSM code I'd posted a year or
so earlier. And I'm not claiming I invented it because it is (to use
your term) kindergarten programming compared to what MLG has done in his
CHOOSE solution and other published work.

And while we're on about rquotations that you continually brag about,
you never point out that they need system specific assembler code and
that they are riddled with ambiguous behaviour (disguised as 'you can't
this, that or the other'). This of course is double standards behaviour
from someone who has a record of ranting about ANS Forth having
ambiguous behaviour.

> --- he doesn't know about the problem of MLG using the wrong sort
algorithm.

How could he use a wrong sort algorithm when he didn't do an explicit
sort. Look at his code.

> Because of this, the "stage" where Gerry writes something comparable to my SLOW-SWITCH>

Note that SLOW-SWITCH and FAST-Switch have an awful syntax compared to
MLG's CHOOSE

> that supports a sparse set of selectors has never arrived.

because I've not tried as yet. Look who's talking - Straight Forth has
never arrived, how long is it now since you first wrote about it - over
12 years I believe.

> This is very typical of maintenance programmers. They claim to be instant experts on somebody's
> code, but they don't understand how the code works --- they never succeed at anything.
>

Using your non-logic as you don't understand my code or MLG's you must
be a maintenance programmer. I don't know why you use the term
'maintenance programmer' as an insult.

Given that you've recently written elsewhere:

> In the 25 years since I wrote MFX at Testra, there has been a parade of
> maintenance programmers at Testra brown-nosing Tom Hart, telling him
> that he is a genius, etc.. None of the maintenance programmers succeeded
> in figuring out how MFX works. They just collected paychecks for as
> long as
> they could get away with it, then left to go brown-nose somebody else.
> Tom Hart doesn't know how MFX works either --- he is hoping that somebody
> will come along and explain it to him. Tom Hart still has UR/Forth
> running
> at Testra so my MFX will continue to run, because none of the maintenance
> programmers understood it well enough to port it to a more modern Forth.
>

I've known maintenance programmers complaining about arrogant
development programmers writing messy, unstructured and poorly
documented code and then expecting other people to maintain the crap.
How do we know that isn't the case at Testra with MFX?

--
Gerry

On Thursday, June 24, 2021 at 3:28:07 PM UTC-7, Gerry Jackson wrote:
> On 14/06/2021 03:06, Hugh Aguilar wrote:
> > A good example of non-robust code is in this thread:
> > https://groups.google.com/g/comp.lang.forth/c/HwxAddZ54mg/m/-Miq-hqQAQAJ
> >
> > On Wednesday, June 17, 2020 at 12:05:23 AM UTC-7, hughag...@gmail.com wrote:
> >> As I have said many times in the past, the bucket-sort only works when
> >> the values are within a small range. The bucket-sort fails when the
> >> values are in a wide range that is too big for an array of buckets.
> >> This is why Michael Gassanenko's algorithm is no good for a sparse set
> >> of selector values --- their range is too big for an array of buckets.
> >
> Sigh, so many lies and much abuse. Normally I now ignore your posts but
> as you make a libellous statement about me this is to put the record
> straight and to show newbies what a gobshite you are.
> > Michael Gassanenko's CHOOSE (switch) code was not robust. He succeeded
> > in getting the jump-table working, comparable to my FAST-SWITCH> but he did not
> > succeed in getting a sparse jump-table working because he used a bucket-sort
> > that is restricted to a small range of values,
> Wrong Michael Gassanenko (MLG) does no explicit sorting, you don't
> understand what he's done. Also how can you say he did not succeed at
> something when you have no evidence he actually tried.

Gerry Jackson is a fountain of bullshit!
Gassanenko's code uses a bucket-sort. The jump-table is the array of buckets. Duh!
This doesn't scale up to anything like my SLOW-SWITCH> that has a sparse array.
I sorted my data in an intermediate data-structure (linked list) and then FAST-SWITCH>
generated the jump-table from that, or SLOW-SWITCH> generated the compacted
jump-table that needs to be searched at run-time with a binary search.
Gassanenko's code just went straight to the jump-table (like my FAST-SWITCH>)
which is effectively a bucket-sort --- not appropriate for a wide range of values.

> > This thread is also a good example of a maintenance programmer (Gerry Jackson)
> Wrong, you're the fool, I've never worked as a maintenance programmer.
> > making a complete fool out of himself.
> Gratuitous insult time again by a malicious troll
> > Gerry stole Gassanenko's code and put > his own copyright on it.
> Wrong, that's a libel and can easily be disproved by looking at the
> source code of Michael Gassanenko and mine at:
> https://github.com/gerryjackson/Forth-switch

Your code was about 95% stolen from Michael Gassanenko.
You made a trivial modification (making it ANS-Forth compliant at the
sacrifice of his nice syntax), then put your copyright on it.
This is very typical behavior for a maintenance programmer, to steal someone's code,
make a trivial upgrade, then copyright it.

This is my code:
---------------------------------------------------------------------
\ ******
\ ****** This is a <SWITCH control-structure like in C that generates a jump-table.
\ ******

\ You can build a colon word called XXX that switches on targ values. This is how:
\ <SWITCH
\ :NONAME drop ... ; targ CASE-OF
\ ...
\ :NONAME drop ... ; FAST-SWITCH> xxx ( selector -- )

\ The DROP in the :NONAME function gets rid of the selector-value. You might need this sometimes though.

\ There are some simple additions, that can be used instead of CASE-OF (they do CASE-OF internally):
\ :NONAME drop ... ; low-targ high-targ RANGE-OF \ matches all of the values from LOW-TARG to HIGH-TARG inclusive
\ :NONAME drop ... ; ." xxx" CHARS-OF \ matches all of the chars in the string
\ :NONAME drop ... ; <WHEN ... WHEN> \ matches all of the values between <WHEN and WHEN> (the .... means zero or more values)

\ Also, we have CASE: suggested by DXForth that can be used instead of CASE-OF .

\ The colon word XXX executes a table-entry corresponding to the targ value.
\ If there is no match, then the xt value prior to FAST-SWITCH> is executed as the default.
\ All of the table-entries and the default are given the selector value which they DROP if not needed.
\ It was HAA's suggestion that the selector value be provided --- I had dropped it internally previously.

\ The targ values don't have to be provided in any particular order --- they get sorted internally.
\ If a duplicate targ value is provided, CASE-OF will abort with an error message at compile-time.
\ This error message shows which line had the duplicate, and what the duplicate value is
\ (This helpful error message is an improvement over Michael Gassanenko's CHOOSE).
\ Note that my <WHEN ... WHEN> was written to provide comparable functionality to Michael Gassanenko's CHOOSE code.

\ This is pretty crude because, unlike in C, the table entries can't have common local variables.
\ I would have liked to use my rquotations, but they don't have an xt that is known at compile-time,
\ so it is not possible to build a jump-table at compile-time. They have a "continuation" that is only known at run-time.
\ My <SWITCH that I have here uses :NONAME for the table entries --- they can have common global variables.

\ FAST-SWITCH> uses the selector value as an index to do the table look up. This is very fast.
\ If the range is too large however, then FAST-SWITCH> will abort with an error message to save memory.
\ In this case, use SLOW-SWITCH> instead. This builds a smaller table and uses BSEARCH to look up the table-entry.

\ Set JT-LIMIT to the range that you want FAST-SWITCH> to support.
\ It is currently set at 2^16 so you can have jump-tables with up to 64K entries. These consume a lot of memory.
\ If memory usage is an issue, then set JT-LIMIT to a smaller value. Use SLOW-SWITCH> instead of FAST-SWITCH>.
\ If the jump-table is sparse, SLOW-SWITCH> might be faster because there is less data-cache thrashing.

\ <SWITCH is primarily provided for writing VM simulators.
\ JT-LIMIT is currently set at 2^16, so it supports simulating a micro-processor with 16-bit opcodes (such as the AVR).
\ SLOW-SWITCH> would be needed for a micro-processor with 32-bit opcodes (such as the ARM or MIPS).

\ Some micro-processors (or byte-code VMs) have 8-bit opcodes, but also have post-bytes on some of the opcodes.
\ These variable-sized opcodes could be done with nested FAST-SWITCH> constructs.

list
w field .xt
w field .targ
constant jt

: init-jt ( xt targ node -- node )
init-list >r
r@ .targ !
r@ .xt !
r> ;

: new-jt ( xt targ -- node )
jt alloc
init-jt ;

: kill-jt ( head -- )
each[ dealloc ]each ;

: show-jt ( head -- )
each[ cr .targ @ . ]each ;

: jt> ( new-node node -- new-node flag ) \ used by INSERT-ORDERED to build an ascending list without duplicates
.targ @ over .targ @
2dup = if
cr ." targ value: " dup . dup h. dup b. dup 128 < if dup 32 > if ." char: " dup emit then then
cr true abort" *** <SWITCH structures not allowed to have duplicate targ values ***"
then
> ;

variable when-marker \ used by <WHEN values... WHEN> to determine how many values there are on the data-stack

: <switch ( -- head )
false when-marker !
nil ;

: case-of ( head xt targ -- new-head ) \ provide a targ value
new-jt \ -- head node
['] jt> swap insert-ordered drop ;

: range-of { head xt lo hi -- new-head } \ provide a range from LO to HI inclusive
head
hi 1+ lo do
xt I case-of
loop ;

: chars-of { head xt adr cnt -- new-head } \ provide a string containing targ chars
head
adr cnt + adr do
xt I c@ case-of
loop ;

: <when ( head xt -- head xt ) \ saves the depth after HEAD XT in WHEN-MARKER
when-marker @ abort" *** <WHEN can't be nested ***"
depth when-marker ! ;

: when> ( head xt values... )
when-marker @ 0= abort" *** <WHEN is needed prior to the values prior to the WHEN> ***"
depth when-marker @ - { total | cnt xt -- }
total 0< abort" *** WHEN> given an invalid marker ***"
total to cnt begin cnt while >r -1 +to cnt repeat \ -- head xt \return: -- values...
to xt \ -- head \return: -- values...
total to cnt begin cnt while xt r> case-of -1 +to cnt repeat \ -- new-head \return: --
false when-marker ! ; \ a <WHEN is needed to set WHEN-MARKER for the next WHEN>

: digit-of ( head xt -- new-head )
[char] 0 [char] 9 range-of ;

: lower-of ( head xt -- new-head )
[char] a [char] z range-of ;

: upper-of ( head xt -- new-head )
[char] A [char] Z range-of ;

: alpha-of { head xt -- new-head }
head
xt lower-of xt upper-of ;

: punctuation-of ( head xt -- new-head )
s| .,!?'";:[]()@#$%&| chars-of ;

On Thursday, June 24, 2021 at 3:28:07 PM UTC-7, Gerry Jackson wrote:

Here we have Alex Wegel not knowing what the word "robust" means.

> On 14/06/2021 03:06, Hugh Aguilar wrote:
> > Alex Wegel doesn't know what the word "robust" means.
> > The word "robust" in regard to software means that the software can be
> > modified easily to accommodate changing requirements and/or
> > additional requirements (such as adding 7 to the special numbers in fizz-buzz).
> >
> > The word "robust" does not mean doing nit-picking error-checking looking for
> > unlikely input values, such as checking for a resistor value of zero (I really doubt
> > that the user will be working with super-conductors that have zero resistance).

And here we have Gerry Jackson not knowing what the word "ambiguous" means.

> And while we're on about rquotations that you continually brag about,
> you never point out that they need system specific assembler code and
> that they are riddled with ambiguous behaviour (disguised as 'you can't
> this, that or the other'). This of course is double standards behaviour
> from someone who has a record of ranting about ANS Forth having
> ambiguous behaviour.

The word "ambiguous" in regard to software means that a word will
mean different things in different supposedly compatible systems.

The word "ambiguous" does not mean that software has restrictions.
All software has restrictions. Duh!

My rquotations have the restriction that they work only if the HOF that executes
them is called directly by the parent function (where the rquotation is defined).
This isn't ambiguous behavior --- this is the same in all rquotation implementations.
This is also a minor restriction --- the HOF typically iterates through the nodes
of a data-structure, so it is just a loop.
This implies that iteration rather than recursion is used for traversing the nodes
of the data-structure, but this is easy --- also, the implementer of the
general-purpose data-structure is presumably a more advanced programmer
than the user of the general-purpose data-structure, so he can make it work.
Implementation of the general-purpose data-structure (writing the HOFs) is done once,
but the general-purpose data-structure my be used hundreds of times, so I would
expect the person writing the HOFs to be able to work with a minor restriction.

My rquotation also has the restriction that it can not have locals of its own, but it only
accesses the locals of the parent function in which it is defined.
This restriction is extremely trivial --- this will never be a problem.

All in all, I think my rquotations are a good solution for implementing
general-purpose data-structures. Ilya Tarasov's nested definitions are also good.
GCC has nested definitions too, but these are not ANSI-C (ANSI-C is very crude).
The Forth-200x committee has nothing to offer whatsoever --- the Paysan-faked
quotations are very crude --- the idea of using :NONAME for quotations is an example
of incompetents pretending to be experts, and is really uncute.

> > In the 25 years since I wrote MFX at Testra, there has been a parade of
> > maintenance programmers at Testra brown-nosing Tom Hart, telling him
> > that he is a genius, etc.. None of the maintenance programmers succeeded
> > in figuring out how MFX works. They just collected paychecks for as
> > long as
> > they could get away with it, then left to go brown-nose somebody else.
> > Tom Hart doesn't know how MFX works either --- he is hoping that somebody
> > will come along and explain it to him. Tom Hart still has UR/Forth
> > running
> > at Testra so my MFX will continue to run, because none of the maintenance
> > programmers understood it well enough to port it to a more modern Forth.
>
> I've known maintenance programmers complaining about arrogant
> development programmers writing messy, unstructured and poorly
> documented code and then expecting other people to maintain the crap.
> How do we know that isn't the case at Testra with MFX?

VLIW is a tough subject. The concept of parallel execution of instructions
and out-of-ordering the instructions was difficult to figure out, but I figured it out.
Tom Hart's claim that I can't follow directions is bullshit --- I never had any directions
or helpful hints or even a specification for what the assembler was supposed to do.
I just had to figure everything out entirely on my own.
Gerry Jackson is not my peer. He would not be able to figure this out
from scratch, and not even if he were given my already working source-code.
None of the Forth-200x committee would succeed.
This is not because my code is "crap" --- this is because they are dumb.

On 27/06/2021 08:36, Hugh Aguilar wrote:
> ...
> Tom Hart's claim that I can't follow directions is bullshit --- I never had any directions
> or helpful hints or even a specification for what the assembler was supposed to do.
> I just had to figure everything out entirely on my own.

Well, that's nothing new. In many fields the technician frequently has more
specific information than the manager by virtue of the work he does. He's
paid to apply it within the bounds set by management. 'Not taking direction'
means not accepting managerial instruction when given.

Hugh Aguilar <hughaguilar96@gmail.com> wrote:

> On Thursday, June 24, 2021 at 3:28:07 PM UTC-7, Gerry Jackson wrote:
>
> Here we have Alex Wegel not knowing what the word "robust" means.

No we don't. We only have Hugo quoting himself.

> > On 14/06/2021 03:06, Hugh Aguilar wrote:
> > > Alex Wegel doesn't know what the word "robust" means.
> > > The word "robust" in regard to software means that the software can be
> > > modified easily to accommodate changing requirements and/or
> > > additional requirements (such as adding 7 to the special numbers in fizz-
buzz).
> > >
> > > The word "robust" does not mean doing nit-picking error-checking looking
for
> > > unlikely input values, such as checking for a resistor value of zero (I
really doubt
> > > that the user will be working with super-conductors that have zero
resistance).

So you (again) resort to playing stupid, in order to win an argument?

Or are you really stupid enough to think that an integer(!) argument of
zero means super-conductivity?

Occams razor has the answer: You're just being a dumb prick playing
stupid.

And: There's no way to add 7 to fizz-buzz, because then it would be
fizz-buzz-barf.
This is just yet another
straw-hugh-moving-the-goal-posts-for-arguments-sake.

> > > In the 25 years since I wrote MFX at Testra, there has been a parade of
> > > maintenance programmers at Testra brown-nosing Tom Hart, telling him
> > > that he is a genius, etc..

Name one of them - or is this just another Hate-Hog fantasy?

> > > None of the maintenance programmers succeeded
> > > in figuring out how MFX works.

That's pretty much the definition of unmaintainable.

> > > They just collected paychecks for as
> > > long as
> > > they could get away with it, then left to go brown-nose somebody else.

...and you envy them (for their paychecks).

> > > Tom Hart doesn't know how MFX works either --- he is hoping that somebody
> > > will come along and explain it to him. Tom Hart still has UR/Forth
> > > running
> > > at Testra so my MFX will continue to run, because none of the maintenance
> > > programmers understood it well enough to port it to a more modern Forth.

So, *whose* fault might *that* have been?

> Tom Hart's claim that I can't follow directions is bullshit --- I never had
any directions
> or helpful hints or even a specification for what the assembler was supposed
to do.

My guess based on your performance here is that you didn't listen, or
failed to read properly, or just didn't understand.

On 26/06/2021 23:36, Hugh Aguilar wrote:
> On Thursday, June 24, 2021 at 3:28:07 PM UTC-7, Gerry Jackson wrote:
>
> And here we have Gerry Jackson not knowing what the word "ambiguous" means.

Wrong. In the ANS Forth standard the specifcation of many words such as
>R states that interpretation semantics are undefined.

Section 4.1.2 Ambiguous conditions contains:
" - interpretating [sic] a word with undefined interpretation semantics"

>
>> And while we're on about rquotations that you continually brag about,
>> you never point out that they need system specific assembler code and
>> that they are riddled with ambiguous behaviour (disguised as 'you can't
>> this, that or the other'). This of course is double standards behaviour
>> from someone who has a record of ranting about ANS Forth having
>> ambiguous behaviour.
>
> The word "ambiguous" in regard to software means that a word will
> mean different things in different supposedly compatible systems.
>
> The word "ambiguous" does not mean that software has restrictions.
> All software has restrictions. Duh!

Yes, Captain Bleeding Obvious. But if you can't tell what a Forth system
will do if someone ignores a restriction the result is ambiguous. You
need to define the behaviour for such cases to make it unambiguous e.g.
report an error. But that is probably more trouble than it's worth so it
just gets documented as ambiguous.

>
> My rquotations have the restriction that they work only if the HOF that executes
> them is called directly by the parent function (where the rquotation is defined).
> This isn't ambiguous behavior --- this is the same in all rquotation implementations.

> This is also a minor restriction --- the HOF typically iterates through the nodes
> of a data-structure, so it is just a loop.
expect the person writing the HOFs to be able to work with a minor
restriction.
>
> My rquotation also has the restriction that it can not have locals of its own, but it only
> accesses the locals of the parent function in which it is defined.
> This restriction is extremely trivial --- this will never be a problem.

Until it is.

>
> All in all, I think my rquotations

(which are an extension of Humpty Dumpty's rquotations)

> are a good solutionfor implementing general-purpose data-structures.

....

>>> In the 25 years since I wrote MFX at Testra, there has been a parade of
>>> maintenance programmers at Testra brown-nosing Tom Hart, telling him
>>> that he is a genius, etc.. None of the maintenance programmers succeeded
>>> in figuring out how MFX works.

....

>> I've known maintenance programmers complaining about arrogant
>> development programmers writing messy, unstructured and poorly
>> documented code and then expecting other people to maintain the crap.
>> How do we know that isn't the case at Testra with MFX?

By not answering this you're just admitting that you hadn't adequately
documented MFX etc

--
Gerry

On Sunday, June 27, 2021 at 6:59:39 AM UTC-7, Gerry Jackson wrote:
> On 26/06/2021 23:36, Hugh Aguilar wrote:
> > On Thursday, June 24, 2021 at 3:28:07 PM UTC-7, Gerry Jackson wrote:
> >
> > And here we have Gerry Jackson not knowing what the word "ambiguous" means.
> Wrong. In the ANS Forth standard the specifcation of many words such as
> >R states that interpretation semantics are undefined.
>
> Section 4.1.2 Ambiguous conditions contains:
> " - interpretating [sic] a word with undefined interpretation semantics"

This is an example of Gerry Jackson not knowing what disambiguifiers do.
I never said that the disambiguifiers allow words with undefined interpretation semantics
to be interpreted. I said that the disambiguifiers allow FIND and tick etc. to work in an
unambiguous manner when given the name of the disambiguified word.

This has already been covered here:
https://groups.google.com/g/comp.lang.forth/c/y96tQf_iOSk/m/WhpmjMTeAgAJ

On Thursday, August 1, 2019 at 4:42:04 AM UTC-7, hughag...@gmail.com wrote:
> On Monday, July 29, 2019 at 11:34:50 AM UTC-7, Gerry Jackson wrote:
> > Note
> > 1. During the compilation of PPP4 the text interpreter never encounters
> > the *name* POSTPONE and so doesn't try to interpret it. It interprets
> > POSTPONE-POSTPONE which does have interpretation semantics.
> >
> > 2. Nowhere in the standard does it say that the word [ suspends or stops
> > compilation of the current definition. It merely sets STATE to 0 and
> > lets the text interpreter carry on.
> >
> > 3. Nowhere in the standard does it say that words whose compilation
> > semantics are *indirectly* executed (such as POSTPONE via
> > POSTPONE-POSTPONE in the definition of PPP4) between [ and ] cannot
> > cause something to be compiled.
> >
> > 4. Nowhere in the standard does it say that the compilation semantics of
> > POSTPONE depend on the value held in STATE.
> >
> > 5. I believe the above is true for the other words with undefined
> > interpretation semantics.
>
> This isn't true for any of the words with
> undefined interpretation semantics.
> If it were true, then words such as R> IF ABORT" etc. could be used
> whenever STATE is zero, such as inside of [ ... ] brackets,
> or even outside of colon definitions at the command-line!
>
> Gerry Jackson believes that by burying the "no interpretation semantics"
> word inside of disambiguifier with POSTPONE , he has quibbled away
> the fact that it is being interpreted. This isn't true.
> Just because its *name* isn't being found by the text interpreter
> doesn't mean that it isn't being interpreted when it executes.
>
> There is really no difference between executing a disambiguified word
> or the pre-disambiguified word. It does the same thing either way.
> The disambiguification only affects what FIND does when given the name
> of the word. The disambiguifier allows FIND to find an xt, it allows
> FIND to return the same xt whether STATE is true or false when FIND
> executes, and it allows FIND to indicate that the word is immediate.
> That is all that the disambiguifier does.
> The disambiguifier doesn't give the word any new properties that
> it didn't previously have, or change how it behaves in any way
> (except you get a warning message when you execute it when STATE
> is zero; this was always illegal, but you didn't get warned previously).
>
> The disambiguifiers cause FIND to work.
> For years I thought that FIND was irrevocably broken and hence that
> ANS-Forth was utterly useless for cross-compilation.
> Then I figured out how the disambiguifiers fix FIND
> (actually, Anton Ertl told me about the disambiguifiers back in 2009
> when I was just starting on ANS-Forth, but it took years to grok this).
> The disambiguifiers cause FIND to work, which is a good thing.
> The disambiguifiers don't have magical powers though -- they don't
> allow words such as R> IF ABORT" etc. to work when STATE is zero ---
> this continues to be illegal in ANS-Forth, as it should be.
>
> > Conclusions
> > 1. Hugh has missed the point about the "text interpreter encountering
> > the name" and is mistaken in his belief that the interpretation
> > semantics of POSTPONE are executed in PPP4.
> > 2. Hugh shouldn't complain about the use of 'goofy terminology' (his
> > words) such as compilation semantics, which are precisely defined,
> > instead of using his own vague terminology.
> > 3. Hugh should read the standard carefully before mistakenly ranting
> > about it
> > 4. Hugh should apologise to Anton and Alex for continually calling them
> > liars
> > 5. The disambiguifiers that Hugh continually (and I might say
> > tiresomely) brags about are non-compliant with respect to the ANS Forth
> > and Forth 2012 standards because the above code won't work. Furthermore
> > a program using them wouldn't be a standard program.
>
> Gerry Jackson has joined the liars Anton Ertl and Alex McDonald
> in telling this preposterous lie, founded upon magical thinking.

On 27/06/2021 20:06, Hugh Aguilar wrote:
> On Sunday, June 27, 2021 at 6:59:39 AM UTC-7, Gerry Jackson wrote:
>> On 26/06/2021 23:36, Hugh Aguilar wrote:
>>> On Thursday, June 24, 2021 at 3:28:07 PM UTC-7, Gerry Jackson wrote:
>>>
>>> And here we have Gerry Jackson not knowing what the word "ambiguous" means.
>> Wrong. In the ANS Forth standard the specifcation of many words such as
>>> R states that interpretation semantics are undefined.
>>
>> Section 4.1.2 Ambiguous conditions contains:
>> " - interpretating [sic] a word with undefined interpretation semantics"
>
> This is an example of Gerry Jackson not knowing what disambiguifiers do.
> I never said that the disambiguifiers allow words with undefined interpretation semantics
> to be interpreted. I said that the disambiguifiers allow FIND and tick etc. to work in an
> unambiguous manner when given the name of the disambiguified word.

A typical Aguilar response, changing the subject when proven wrong.

....

and repeatedly posting stuff that nobody ever reads

--
Gerry