The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

[JUERGEN]

It took longer than expected, but as Stephen allowed me to reformat his book for publication on amazon, it had to be finished - came out today https://www.amazon.co.uk/dp/B01JIWVB5S or your local amazon.
After Chuck Moore - Early Years https://www.amazon.de/dp/B00JZI64U8
and Chuck Moore - Programming a Problem Oriented Language https://www.amazon.de/dp/B00K3PIYX2
leading to the Forth Lite Tutorial - https://www.amazon.de/dp/B00L0F32Q8
we have 4 now.
Enjoy Stephen's eBook.

[Paul Rubin]

JUERGEN <epld...@aol.com> writes:
> It took longer than expected, but as Stephen allowed me to reformat
> his book for publication on amazon, it had to be finished - came out
> today https://www.amazon.co.uk/dp/B01JIWVB5S

Neat! Is this (reformatted) the same book as on the MPE web site? I
don't use a Kindle myself, but Kindle users will probably appreciate the
conversion.

[JUERGEN]

Yes it is the same, just 2 little bits added, especially some info about the Sockpuppet, but a lot of bookmarks, links and formatting. I added bookmarks as it was missing in most other Forth books I had seen - where is the word described in the book? Many here will not need the book to learn - but this is not the real target group.

[Brad Eckert]

On Tuesday, August 2, 2016 at 9:33:47 AM UTC-7, JUERGEN wrote:
> It took longer than expected, but as Stephen allowed me to reformat his book for publication on amazon, it had to be finished - came out today https://www.amazon.co.uk/dp/B01JIWVB5S or your local amazon.

No hard copy? It looks like my tree-killing days are numbered.

[Cecil Bayona]

I have an extensive library on electronics, programming, and ham radio,
but the last few years I buy a Kindle version when possible. When not
available I buy a used hardbound copy if possible. I bought six books
today, five were programming books in Kindle versions, one was a old
hardbound book on Forth for $3.99 including shipping.

--
Cecil - k5nwa

[JUERGEN]

Until now I preferred eBooks, as of lower cost or free. But with books like this one and as formatting is uncontrollable unfortunately, a printed version is under consideration - but cannot be read on mobile or tablet. So the usual swings and roundabouts.

[rickman]

Can't you print a copy?

--

Rick C

[hughag...@gmail.com]

On Tuesday, August 2, 2016 at 11:46:25 AM UTC-7, JUERGEN wrote:
> On Tuesday, August 2, 2016 at 6:35:52 PM UTC+1, Paul Rubin wrote:
> > JUERGEN <epld...@aol.com> writes:
> > > It took longer than expected, but as Stephen allowed me to reformat
> > > his book for publication on amazon, it had to be finished - came out
> > > today https://www.amazon.co.uk/dp/B01JIWVB5S
> >
> > Neat! Is this (reformatted) the same book as on the MPE web site? I
> > don't use a Kindle myself, but Kindle users will probably appreciate the
> > conversion.
>

> Yes it is the same... Many here will not need the book to learn - but this is not the real target group.

Juergen Pintaske is a salesman for MPE --- he wasn't "allowed" to reformat the book --- it was just a work assignement.

The problem is not that I don't need the book to learn --- the problem is that the book teaches Forth badly --- makes Forth look stupid.

Here is an example from the book:

: 2Array \ n1 n2 -- ; [child] n1 n2 -- addr ; 2-D array
Create \ create data word
Over , \ save width for run-time
cell * * \ calculate size
Here over erase \ clear memory
allot \ reserve n cells
Does> \ run time gives address of data
Dup @ Rot * Rot + 1+
cell *
+
;

This is horrible Forth code! For one thing, the ARRAY definer only supports cell-sized elements. What if you need an array of floats? You have to cut-and-paste-and-modify this code to make it work. This is not a general-purpose data-structure! By comparison, I have support for arrays in the novice-package that allow the arrays to be of any sized elements.

For another thing, the code is grossly inefficient. It is fetching the width of the array from memory at run-time --- this is an immutable constant however --- it is known at compile-time and it never changes, so it doesn't need to be stored in memory, but it can be a literal. Also, this constant value is being given to * for multiplication. If it is a power of two (it usually is) then it should get compiled as a SHL --- instead it gets compiled as an IMUL --- by comparison, my arrays in the novice-package compile into shifts rather than multiplications when they are powers of two.

Here is another example from Stephen Pelc's book:

0 constant [struct \ -- 0 ; start
\ Start a structure definition, returning zero as
\ the initial offset.
: field \ offset n -- offset+n ; addr -- addr+offset
\ When defining a structure, a field of size n starts
\ at the given offset, returning the next offset. At
\ run time, the offset is added to the base address.
create
over , + \ lay offset and update
does>
@ + \ addr offset to address
;
: struct] \ offset -- ; -- size ; end
\ End a structure definition by naming it.
constant
;

This is more horrible Forth code! Pelc says: "The first and third words are just syntactic sugar to make the code easier to read." This doesn't make the code easier to read however. This conceals the fact that one struct can inherit from another struct. General-purpose data-structures rely heavily on inheritance --- you can't have general-purpose data-structures without inheritance --- by forcing the base value to be 0, Pelc is effectively denying the possibility of inheritance.

Also, this is grossly inefficient code. It is a CREATE DOES> word, so a CALL is required. Also, it is fetching the offset from memory, but this is a constant that is known at compile-time so it should be a literal. Also, if this value is zero (it is for the first field) then it still gets fetch from memory and added, although this is not necessary. Also, Pelc is not aligning his fields and making their size a multiple of the cell size --- this boosts speed considerably on modern processors (everything after the 1980s) --- this is also required for my SORT to work (because EXCHANGE requires the element size to be a multiple of the cell size).

All in all, I would not recommend anybody to read this book, because it makes Forth look stupid. A lot of the Forth novices are already reasonably expert in C --- they are going to read this book and go away with the belief that Forth is a toy language --- they are going to use this book as proof that Forth programmers lack an understanding of even the most rudimentary programming concepts.

[hughag...@gmail.com]

On Tuesday, August 2, 2016 at 5:56:17 PM UTC-7, Cecil - k5nwa wrote:
> I have an extensive library on electronics, programming, and ham radio,
> but the last few years I buy a Kindle version when possible. When not
> available I buy a used hardbound copy if possible. I bought six books
> today, five were programming books in Kindle versions, one was a old
> hardbound book on Forth for $3.99 including shipping.

The only hard-bound book on Forth that I'm aware of was: "Threaded Interpretive Languages" (R.G.Loeliger). Is this the one that you mean? It is a pretty good book --- I read that when I was 18 years old and still in high-school --- then I lent it to a guy out at the college and he moved away without returning it.

[Cecil Bayona]

I bought today a hard cover book on Forth, below that one are several
other Hardcover Forth books;

"Forth: The New Model : A Programmer's Handbook/Book and Disk", can't
tell you anything about it, it's a pig in a poke, it was cheap and never
heard of it so I took a chance and bought it.

"Embedded Controller Forth For The 8051 Family" is also a hardback book
but it is outrageously priced.

"Forth Tools and Applications" is another hardback book on Forth. $39

"Forth: The Fourth-Generation Language" $1539.03, insane price.

"Forth for Professionals: A Practical Programming Language for Research
and Development" $1941.21, these people are insane.

"FORTH: a Complete Course in the Forth Programming Language", $50
--
Cecil - k5nwa

[hughag...@gmail.com]

Actually, now that I think about it, there were some other Forth books that made it into hard-cover. I have "Embedded Controller Forth For The 8051 Family" --- that book consists almost entirely of 8051 assembly-language source-code with very little text --- I don't know why it was made into a book rather than distributed on disk (who is going to type all of that in?).

There is also Dick Pountain's book: "Object Oriented Forth" that was hard-cover and which I also have --- I didn't like his OOP system, but I don't remember why now, as that was 30 years ago when I read his book --- I have a super-simple OOP system in the novice-package that works well for me.

[Cecil Bayona]

The embedded book for 8051 is $54 for a used copy, too much if it
doesn't include the listing as a readable file somewhere.

The list I provided are all found in Hard Binding, but those are the
ones found on Amazon, there could be others, there was a surprising
number of books in paperback form, which surprised me as I only expected
about 1/2 a dozen or so. Most were way overpriced for old used books and
two of them are insane with a price over $1500 for a used book, they
must be working on the theory that that some idiots have more money than
sense.

--
Cecil - k5nwa

[Cecil Bayona]

On 8/3/2016 12:41 PM, hughag...@gmail.com wrote:

Found another one;

"FORTH: Applications in Engineering and Industry" $2.63 + shipping, I
bought it, it was cheap, most likely quite useless.

--
Cecil - k5nwa

[rickman]

Back in the day I bought a couple/three Forth books. They turned out to
be pretty lame for the most part. I think the good ones are written by
the more commercial elements represented here. They have a strong
motivation to produce quality training materials.

--

Rick C

[Roberto Waltman]

hughag...@gmail.com wrote:

>The only hard-bound book on Forth that I'm aware of was: "Threaded Interpretive Languages" (R.G.Loeliger).

Also hard-bound:
[ Kelly & Spies ] "FORTH: a Text and Reference" and
[ Payne ] "Embedded Controller FORTH"

R.W.

[Richard Owlett]

On 8/3/2016 1:15 PM, rickman wrote:
>
> Back in the day I bought a couple/three Forth books. They turned
> out to be pretty lame for the most part. I think the good ones
> are written by the more commercial elements represented here.
> They have a strong motivation to produce quality training materials.
>

When I first tried Forth I went commercial just for that reason.
I needed the comfort factor.

[hughag...@gmail.com]

On Wednesday, August 3, 2016 at 12:04:34 AM UTC-7, hughag...@gmail.com wrote:
> Here is another example from Stephen Pelc's book:
>
> 0 constant [struct \ -- 0 ; start
> \ Start a structure definition, returning zero as
> \ the initial offset.
> : field \ offset n -- offset+n ; addr -- addr+offset
> \ When defining a structure, a field of size n starts
> \ at the given offset, returning the next offset. At
> \ run time, the offset is added to the base address.
> create
> over , + \ lay offset and update
> does>
> @ + \ addr offset to address
> ;
> : struct] \ offset -- ; -- size ; end
> \ End a structure definition by naming it.
> constant
> ;
>
> This is more horrible Forth code! Pelc says: "The first and third words are just syntactic sugar to make the code easier to read." This doesn't make the code easier to read however. This conceals the fact that one struct can inherit from another struct. General-purpose data-structures rely heavily on inheritance --- you can't have general-purpose data-structures without inheritance --- by forcing the base value to be 0, Pelc is effectively denying the possibility of inheritance.
>
> Also, this is grossly inefficient code. It is a CREATE DOES> word, so a CALL is required. Also, it is fetching the offset from memory, but this is a constant that is known at compile-time so it should be a literal. Also, if this value is zero (it is for the first field) then it still gets fetch from memory and added, although this is not necessary. Also, Pelc is not aligning his fields and making their size a multiple of the cell size --- this boosts speed considerably on modern processors (everything after the 1980s) --- this is also required for my SORT to work (because EXCHANGE requires the element size to be a multiple of the cell size).

If I were to write a book on Forth, I would do it completely differently than Pelc did. I would not start right out by providing low-level code such as ARRAY and FIELD --- this is too complicated for a novice to understand because it involves meta-compiling --- and and idiots' version written with CREATE DOES> has serious problems that tend to make Forth look stupid to people who already know C or some other such language.

Instead, I would tell the reader to load the novice-package, and I would provide documentation on how to use the low-level code therein for writing application programs, but I would discourage the readers from delving into the internal workings of the low-level code until after they have written a few application programs and progressed to at least an intermediate level of Forth ability.

Pelc's own code tends to be horrible. Here is an example:
----------------------------------------------------------------------------
struct itimer \ -- len
\ *G Interval timer structure.
\ *[
cell field itlink \ link to next timer ; MUST be first
cell field itTimerId \ timer ID
cell field itinterval \ period of timer in MS
cell field ittimeout \ next timeout
cell field itmode \ mode/flags, 0=periodic, 1=one shot
cell field itxt \ word to execute
end-struct

: do-timers \ -- ; process all the timers in the chain
active-timers @
begin
dup
while \ -- struct
dup itlink @ swap \ get next in chain
dup ittimeout @ ticks - 0< if \ if the interval has expired
dup itxt @ execute \ run the word
dup itmode @ single-shot = if \ if a single shot timer
release-timer \ dispose of the timer
else
dup itinterval @ \ update the timeout point
swap ittimeout +!
endif
else
drop
endif
repeat
drop \ discard the end of chain
;
----------------------------------------------------------------------------

I would start out by teaching the reader how inheritance works. This is pretty basic computer-science and most readers are already going to know about inheritance, but I can still explain it in relation to Forth. I would explain how I have a LIST struct in LIST.4TH and I have words that work on lists, and how any struct that inherits from LIST will get to use all of it parent class's methods. For example, I can define this ITIMER struct as a child of the LIST struct:
----------------------------------------------------------------------------
list
w field .itTimerId
w field .itInterval
w field .itTimeOut
w field .itMode
w field .itXT
constant itimer
----------------------------------------------------------------------------

Then I can explain how the methods of LIST are available. One of those methods is EACH and here is an example of its use:

----------------------------------------------------------------------------
: do-timer { tim -- }
ticks tim .itTimeOut @ u>= if \ expired?
tim .itXT @ execute \ no stack effect
tim itMode @ single-shot = if tim release-timer \ release it
else tim .itInterval @ tim .itTimeOut +! then \ renew it
then ;

: do-timers ( -- )
active-timers @ ['] do-timer each ;
----------------------------------------------------------------------------

I can then explain how EACH has some performance issues, so if speed is very critical then a different technique can be used. But if this technique is used, then there are some issues to consider (debugging is more difficult; it is necessary to remember to not pass data into the loop on the return-stack). Here is an example:

----------------------------------------------------------------------------
: do-timers ( -- )
active-timers @ each[
ticks over .itTimeOut @ u>= if \ expired?
dup .itXT @ execute \ no stack effect
dup .itMode @ single-shot = if dup release-timer \ release it
else dup .itInterval @ over .itTimeOut +! then \ renew it
then
drop ]each ;
----------------------------------------------------------------------------

I can explain that using the return-stack to hold data can improve readability, but it may degrade performance somewhat. This is because the x86 does CALL prediction up to 16 levels deep, but it won't do this when the return-stack is used for holding data, and consequently the code has to be JIT'd again when the RET executes because it hasn't been predicted. This is novice-level assembly-language, so most readers should already know this (it is discussed in Intel's book-2 discussing optimization), but I will explain it anyway. Here is another example that may be more readable but will suffer from this CALL-prediction failure issue:

----------------------------------------------------------------------------
: do-timers ( -- )
active-timers @ each[ >r
ticks r@ .itTimeOut @ u>= if \ expired?
r@ .itXT @ execute \ no stack effect
r@ itMode @ single-shot = if r@ release-timer \ release it
else r@ .itInterval @ r@ .itTimeOut +! then \ renew it
then
rdrop ]each ;
----------------------------------------------------------------------------

So, this is how my book would progress. I would explain concepts, but I would not provide low-level code that the reader is not ready for, and which tends to be pretty tedious and boring for the reader --- examples would be, how arrays and lists are implemented --- I would instead provide examples of high-level code such as DOTIMERS above that use the low-level code. For the most part I would stick with pretty novice-level code that anybody who already knows C and/or x86 assembly-language should find to be pretty easy.

I would focus on explaining concepts, such as inheritance. These are pretty basic concepts that every reader should already know. I would explain these concepts in terms of Forth however, so the reader learns Forth within the context of familiar and not-very-challenging territory. Stephen Pelc wrote his book, but he never mentioned inheritance anywhere --- inheritance is pretty fundamental to programming though --- it should have been mentioned, and in fact should have been the focus of the book.

Here is a good title for the book: "ANS-Forth explained super-simple for dumb-head readers"

[rickman]

So what's stopping you?

> Here is a good title for the book: "ANS-Forth explained super-simple
> for dumb-head readers"

Maybe let someone else name it...

--

Rick C

[Cecil Bayona]

"ANS Forth a guide to alternate realities" that way people on all sides
of the arguments can choose their own meaning to that title.

--
Cecil - k5nwa

[hughag...@gmail.com]

No Forth Inc. book has ever described how to implement structs in Forth (the FIELD definer) and no Forth Inc. book ever will. Stephen Pelc's book discussed in this thread does provide this code:
----------------------------------------------------------------------------

0 constant [struct \ -- 0 ; start
\ Start a structure definition, returning zero as
\ the initial offset.
: field \ offset n -- offset+n ; addr -- addr+offset
\ When defining a structure, a field of size n starts
\ at the given offset, returning the next offset. At
\ run time, the offset is added to the base address.
create
over , + \ lay offset and update
does>
@ + \ addr offset to address
;
: struct] \ offset -- ; -- size ; end
\ End a structure definition by naming it.
constant
;

----------------------------------------------------------------------------
The FIELD words are grossly inefficient because they are defined with CREATE DOES> --- this was fine with Stephen Pelc because he didn't expect anybody to actually use this code --- he wanted to tell people that the use of structs results in inefficient programs, so he purposely made FIELD generate inefficient code.

The worst thing about this code however, is that the [STRUCT word forces the starting offset to be zero. Pelc did this because he wanted to conceal the fact that a struct can inherit from another struct. Most likely, Pelc's background is in C programming, and C forces the starting offset to be zero, so Pelc felt obliged to impose the same limitation on Forth. Pelc's attempt at limiting Forth doesn't actually work though --- Forth is flexible and the Forth programmer can work around these imposed limitations simply by not using [STRUCT --- by comparison, C is inflexible and there is no way for the C programmer to work around these imposed limitations.

Inheritance is a totally taboo subject for the Forth-200x committee (all of whom were appointed to the committee by Elizabeth Rather) --- the Forth-200x committee will do everything in their power to deny the possibility of a child struct inheriting from a parent struct --- this is the key to implementing general-purpose data-structures, which Elizabeth Rather is dead-set opposed to. She said this about my general-purpose data-structures in the novice-package:
----------------------------------------------------------------------------
Does "*every* application" you write use exactly the same kind of data arranged in the same way? If so, having written it once you can reuse it often. If not, you either have to rearrange your data to make it work or modify your "general-purpose" structure.
----------------------------------------------------------------------------

I like Cecil's suggestion for a title to my book: "ANS Forth --- a guide to alternate realities." With a title like that, I would be guaranteed to have exactly zero readers! Who cares about alternate realities? Nobody!

This reminds me of how a lot of people will say that they have an open mind regarding ghosts and discorporal spirits, but in the next breath they will say that they have never seen such a thing and have no expectation that they ever will see such a thing, and they believe that anybody who claims to have seen such a thing is an attention-seeking liar who belongs in a psychiatric hospital. Check out this video:
https://www.youtube.com/watch?v=PfAmEgEjsH0
When people see this video, they typically offer one of the following explanations:
1.) They didn't see any orb. There was no flying orb, there were just the two people; anybody who sees an orb in the video is hallucinating.
2.) The orb was ball lightning. They don't have a definition for the term "ball lightning," but they are sure that scientists do have a definition because it is such a sciency sounding term.
3.) The video was faked. Digital video is composed of pixels that can be modified with PhotoShop or similar software --- the preacher guy most likely paid some graphics-artist to fake up the video in an effort to get people to come to his ministry and donate money.
4.) They didn't watch the video. They saw the title, "Angel Visitation," so they knew immediately that the video was hogwash, and they don't have 30 seconds to spare in their busy schedule for hogwash, so they just didn't watch the video.

The same thing is true of general-purpose data-structures in Forth. I use inheritance routinely throughout the novice-package to implement general-purpose data-structures in ANS-Forth. For example, I have the LIST struct that provides a singly-linked list data-structure, and I have several structs (such as SEQ) that inherit from LIST, and I also have structs that inherit from these structs. Everybody just refuses to look at this; they either say that it doesn't exist, or they say that it does exist but it is "crap." It is a taboo subject! No ANS-Forth programmer will ever admit that general-purpose data-structures exist. Consider this thread:
https://groups.google.com/forum/#!topic/comp.lang.forth/ohE8mx7tWQU%5B126-150%5D
When I provided my hottie-counting function, that killed the thread --- I showed an impossibility! --- nobody wanted to post on the thread anymore because the thread had been tainted with taboo code.

If I wrote a book about general-purpose data-structures in ANS-Forth, nobody would read it. People want to stay within their comfort zone (see Richard Owlett's comment quoted at the top of this post) --- this means that all ANS-Forth code has to rely entirely on cut-and-paste-and-modify of existing programs --- the use of code-libraries is absolutely forbidden!

[Cecil Bayona]

On 8/5/2016 10:35 PM, hughag...@gmail.com wrote:
> On Wednesday, August 3, 2016 at 4:00:48 PM UTC-7, Richard Owlett wrote:

> ----------------------------------------------------------------------------
>
> I like Cecil's suggestion for a title to my book: "ANS Forth --- a guide to alternate realities." With a title like that, I would be guaranteed to have exactly zero readers! Who cares about alternate realities? Nobody!
>

> If I wrote a book about general-purpose data-structures in ANS-Forth, nobody would read it. People want to stay within their comfort zone (see Richard Owlett's comment quoted at the top of this post) --- this means that all ANS-Forth code has to rely entirely on cut-and-paste-and-modify of existing programs --- the use of code-libraries is absolutely forbidden!
>

LOL... I said the title allowed people with different opinions to have
their opinions validated, some people would take it as ANS Forth is an
alternate reality, not based on substance, others would take what you
and others say about Forth as an alternate reality, it's a Politically
Correct title, it makes everyone happy but it's totally without meaning.

A long time ago I started using Borland Delphi for writing work related
and personal software but I could not afford the horribly expensive
database capable version at the time. I ended writing my own Self
Balancing B-Tree multi key database library, it was complex to figure it
out, and it took me a while to get it right, but once it was working I
would use it all over the place. It was very fast, it took little space,
and was very flexible so for years I used it for all sorts of tools and
applications. Yet when I mentioned on this list that it would be nice to
have a library with the much simpler link list, you would have thought I
said that babies should be starved, and burned alive, some people were
all over me criticizing my desire for a convenient link list in a
library, after all Forth itself uses linked list.

The moral here is PC should be flushed down the toilet like the other
items in the toilet, I will have my libraries of items that are
generally useful, no way anyone is going to convince me to write a Self
Balancing B-Tree multi key database or a MySQL interface every time I
need it, it will be waiting in a library ready to use. To that end I
found my source code in Pascal on 3.5" floppies, and a printed listing,
and will look to see if it's feasible to translate it to Forth if so I
need to buy a 3.5" floppy drive, I have 15 PCs including several
laptops, and not one of them has a floppy drive to read the source.

I also have been looking to see if anyone in the past has created a
decent library system, which is another item that is considered heresy
in the Forth community here, yet ANS Forth uses primitive libraries but
most won't admit it, they are called word sets. Recently I saw a post on
ideas for a library system where you can have public and private words,
I will be looking at it next week and see if the ideas are useful for
what I need.
--
Cecil - k5nwa

[hughag...@gmail.com]

On Friday, August 5, 2016 at 10:16:08 PM UTC-7, Cecil - k5nwa wrote:
> A long time ago I started using Borland Delphi for writing work related
> and personal software but I could not afford the horribly expensive
> database capable version at the time. I ended writing my own Self
> Balancing B-Tree multi key database library, it was complex to figure it
> out, and it took me a while to get it right, but once it was working I
> would use it all over the place. It was very fast, it took little space,
> and was very flexible so for years I used it for all sorts of tools and
> applications. Yet when I mentioned on this list that it would be nice to
> have a library with the much simpler link list, you would have thought I
> said that babies should be starved, and burned alive, some people were
> all over me criticizing my desire for a convenient link list in a
> library, after all Forth itself uses linked list.

If you get your self-balancing B-Tree to work, I will put it in the novice-package --- that way you can be sure that nobody will ever use it! --- everything in the novice-package automatically gets dismissed as "crap" by the committee...

I am not aware of any other language in which code-libraries are forbidden. Languages have various levels of support for code-libraries, and the better support the language has, the better the language is. Nobody forbids code-libraries though, other than the ANS-Forth and Forth-200x committees (and COBOL too).

What is sad about this, is that Forth has better support for code-libraries than C does. In C, a struct has to start on offset zero. If the parent struct is made into the first field of the child struct, this won't work because now you need to doubly dereference the field names (use two -> or two . operators). Of course, if you have a struct inheriting from a struct which inherits from another struct, then you have to triply dereference the field names. If you typecast your pointer to the parent struct, you can avoid multiple dereferencing of the field names, but now SIZEOF doesn't work correctly anymore because it gives the parent size rather than the child size. All in all, inheritance in C is a nightmare. By comparison, inheritance in Forth is easy --- yet ANS-Forth culture absolutely forbids having structs inherit from each other --- Pelc went out of his way to give us STRUCT[ which has no purpose at all except to force the starting offset to be zero and hence to make Forth look like C along with C's restrictions against inheritance.

If Forth would embrace inheritance and general-purpose data-structures, this would give Forth an obvious advantage over C --- but the Forth-200x committee seem to be dedicated to imposing C's restrictions on Forth --- the Forth-200x committee wants Forth to be an RPN version of C, with no distinction between Forth and C except postfix-versus-infix (which is really meaningless).

> The moral here is PC should be flushed down the toilet like the other
> items in the toilet, I will have my libraries of items that are
> generally useful, no way anyone is going to convince me to write a Self
> Balancing B-Tree multi key database or a MySQL interface every time I
> need it, it will be waiting in a library ready to use. To that end I
> found my source code in Pascal on 3.5" floppies, and a printed listing,
> and will look to see if it's feasible to translate it to Forth if so I
> need to buy a 3.5" floppy drive, I have 15 PCs including several
> laptops, and not one of them has a floppy drive to read the source.

There are media copying centers available --- you can go there to get obsolete media copied to modern media --- I did that in Denver and it only cost a few dollars (I don't recall now what media format I was getting upgraded, but it was obsolete and yet they did it without difficulty).

> I also have been looking to see if anyone in the past has created a
> decent library system, which is another item that is considered heresy
> in the Forth community here, yet ANS Forth uses primitive libraries but
> most won't admit it, they are called word sets. Recently I saw a post on
> ideas for a library system where you can have public and private words,
> I will be looking at it next week and see if the ideas are useful for
> what I need.

As I mentioned in that thread, I had this working under UR/Forth 30 years ago, but I had to delve into UR/Forth internal workings, so my code wasn't Forth-83.

There has been no improvement in ANS-Forth --- this is still banned, but you may be able to get it working for a specific compiler by delving into the internal workings of that compiler.

What is sad about this, is that it is trivial to implement --- most of the time is spent in disassembling the compiler to figure out how dictionary headers are stored internally --- if you have this info though (the compiler-writer obviously does) then the implementation is the work of one hour or less.

This was banned from ANS-Forth specifically for the purpose of making code-libraries difficult to implement --- you end up with a lot of name clashes --- this makes the code-library less useful, proving the point of those you say that code-libraries are taboo.

[hughag...@gmail.com]

On Saturday, August 6, 2016 at 4:58:14 PM UTC-7, hughag...@gmail.com wrote:
> If Forth would embrace inheritance and general-purpose data-structures, this would give Forth an obvious advantage over C --- but the Forth-200x committee seem to be dedicated to imposing C's restrictions on Forth --- the Forth-200x committee wants Forth to be an RPN version of C, with no distinction between Forth and C except postfix-versus-infix (which is really meaningless).

Most likely, the reason why Elizabeth Rather is opposed to the use of inheritance such as I use in my novice-package, is because Forth Inc. is selling SwiftForth on the basis that it has SWOOP which is a vendor-specific OOP package --- one of their main selling points is that OOP is not available under ANS-Forth --- this is why they don't want a simple OOP system such as mine to be used under ANS-Forth.

[Cecil Bayona]

On 8/6/2016 6:58 PM, hughag...@gmail.com wrote:
> On Friday, August 5, 2016 at 10:16:08 PM UTC-7, Cecil - k5nwa wrote:
>> A long time ago I started using Borland Delphi for writing work related
>> and personal software but I could not afford the horribly expensive
>> database capable version at the time. I ended writing my own Self
>> Balancing B-Tree multi key database library, it was complex to figure it
>> out, and it took me a while to get it right, but once it was working I
>> would use it all over the place. It was very fast, it took little space,
>> and was very flexible so for years I used it for all sorts of tools and
>> applications. Yet when I mentioned on this list that it would be nice to
>> have a library with the much simpler link list, you would have thought I
>> said that babies should be starved, and burned alive, some people were
>> all over me criticizing my desire for a convenient link list in a
>> library, after all Forth itself uses linked list.
>
> If you get your self-balancing B-Tree to work, I will put it in the novice-package --- that way you can be sure that nobody will ever use it! --- everything in the novice-package automatically gets dismissed as "crap" by the committee...
>
> I am not aware of any other language in which code-libraries are forbidden. Languages have various levels of support for code-libraries, and the better support the language has, the better the language is. Nobody forbids code-libraries though, other than the ANS-Forth and Forth-200x committees (and COBOL too).
>
> What is sad about this, is that Forth has better support for code-libraries than C does. In C, a struct has to start on offset zero. If the parent struct is made into the first field of the child struct, this won't work because now you need to doubly dereference the field names (use two -> or two . operators). Of course, if you have a struct inheriting from a struct which inherits from another struct, then you have to triply dereference the field names. If you typecast your pointer to the parent struct, you can avoid multiple dereferencing of the field names, but now SIZEOF doesn't work correctly anymore because it gives the parent size rather than the child size. All in all, inheritance in C is a nightmare. By comparison, inheritance in Forth is easy --- yet ANS-Forth culture absolutely forbids having structs inherit from each other --- Pelc went out of his way to give us STRUCT[ which has no purpose at all except to force the starting offset to be zero and hence to make Forth look like C along with C's restrictions against inheritance.
>
> If Forth would embrace inheritance and general-purpose data-structures, this would give Forth an obvious advantage over C --- but the Forth-200x committee seem to be dedicated to imposing C's restrictions on Forth --- the Forth-200x committee wants Forth to be an RPN version of C, with no distinction between Forth and C except postfix-versus-infix (which is really meaningless).
>
>

I been looking at the printed listing and I'm not sure it will be
practical to translate it to Forth, it makes heavy use of structures,
pointers to structures. With many people demanding that Forth continue
to stay in the 1970s, no libraries, no structures, no decently built
object system, it will be hard to duplicate the Pascal code. Most likely
I will work eventually in an interface to MySQL and leave it at that, no
hurry there. I need MySQL capability eventually as I have several web
sites I maintain and they run on MySQL, I would like to build some
conversion programs to manipulate and modify MySQL databases used in
those sites.

First I need to decide on what Forth system I will use for my desktops
computers, that is why I been playing with different Forth and Forth
like systems. I will be using two different Forths, one for desktops,
with decent library system and tools. The other a stripped down Forth
for embedded systems, I been using eForth for that purpose lately and
it's not bad for that purpose, there are plenty of versions available
for various CPUs, but I have sources to one version that is easily
migrated, I been using it with FPGA Forth CPUs and it's working well.

>> I also have been looking to see if anyone in the past has created a
>> decent library system, which is another item that is considered heresy
>> in the Forth community here, yet ANS Forth uses primitive libraries but
>> most won't admit it, they are called word sets. Recently I saw a post on
>> ideas for a library system where you can have public and private words,
>> I will be looking at it next week and see if the ideas are useful for
>> what I need.
>
> As I mentioned in that thread, I had this working under UR/Forth 30 years ago, but I had to delve into UR/Forth internal workings, so my code wasn't Forth-83.
>
> There has been no improvement in ANS-Forth --- this is still banned, but you may be able to get it working for a specific compiler by delving into the internal workings of that compiler.
>
> What is sad about this, is that it is trivial to implement --- most of the time is spent in disassembling the compiler to figure out how dictionary headers are stored internally --- if you have this info though (the compiler-writer obviously does) then the implementation is the work of one hour or less.
>
> This was banned from ANS-Forth specifically for the purpose of making code-libraries difficult to implement --- you end up with a lot of name clashes --- this makes the code-library less useful, proving the point of those you say that code-libraries are taboo.
>

I remember UR/Forth, never owned it, but they advertised all over, maybe
I should have spent the money but there were many free versions
available so I used those. I wasn't fond of Forth83 just like WinForth
later, it tried to have everything but little in terms of useful modern
programing features.

--
Cecil - k5nwa

[hughag...@gmail.com]

On Saturday, August 6, 2016 at 7:28:45 PM UTC-7, Cecil - k5nwa wrote:
> On 8/6/2016 6:58 PM, hughag...@gmail.com wrote:
> > On Friday, August 5, 2016 at 10:16:08 PM UTC-7, Cecil - k5nwa wrote:
> >> A long time ago I started using Borland Delphi for writing work related
> >> and personal software but I could not afford the horribly expensive
> >> database capable version at the time. I ended writing my own Self
> >> Balancing B-Tree multi key database library, it was complex to figure it
> >> out, and it took me a while to get it right, but once it was working I
> >> would use it all over the place. It was very fast, it took little space,
> >> and was very flexible so for years I used it for all sorts of tools and
> >> applications.

> >> ...

> I been looking at the printed listing and I'm not sure it will be
> practical to translate it to Forth, it makes heavy use of structures,
> pointers to structures. With many people demanding that Forth continue
> to stay in the 1970s, no libraries, no structures, no decently built
> object system, it will be hard to duplicate the Pascal code.

I don't see any problem with porting Pascal code into ANS-Forth --- just ignore the committee and their demand that we don't use structs --- I do fine in my novice-package ignoring them, and if you going to get your code into the novice-package you will have to ignore them too.

I have a book on Pascal-S that supported nested functions. I know that Borland's Turbo-Pascal did not support nested functions though --- it was a trimmed-down non-standard Pascal --- I would assume that Borland's Delphi also did not support nested functions, but I never delved into Delphi very deeply.

If Delphi Pascal is pretty comparable to Turbo Pascal, there should be no difficulty in porting to Forth. I hope that you do provide B-Trees to the novice-package --- I don't know enough about B-Trees to do this myself (without quite a lot of research) --- if you do it though, that would be pretty cool.

> Most likely
> I will work eventually in an interface to MySQL and leave it at that, no
> hurry there. I need MySQL capability eventually as I have several web
> sites I maintain and they run on MySQL, I would like to build some
> conversion programs to manipulate and modify MySQL databases used in
> those sites.
>
> First I need to decide on what Forth system I will use for my desktops
> computers, that is why I been playing with different Forth and Forth
> like systems. I will be using two different Forths, one for desktops,
> with decent library system and tools. The other a stripped down Forth
> for embedded systems, I been using eForth for that purpose lately and
> it's not bad for that purpose, there are plenty of versions available
> for various CPUs, but I have sources to one version that is easily
> migrated, I been using it with FPGA Forth CPUs and it's working well.

Eventually I will bring out Straight Forth. I'm taking my time with that --- I have a lot to learn --- I want to avoid standardizing my ignorance, so I'm holding off on releasing it.

In the meantime, just use VFX. My rquotations work on VFX and SwiftForth --- I could get them to work on any Forth system, most likely, but don't know until I try --- VFX generates pretty fast code, so it could be used for commercial programming.

[Julian Fondren]

On Saturday, August 6, 2016 at 9:28:45 PM UTC-5, Cecil - k5nwa wrote:
> With many people demanding that Forth continue to stay in the 1970s,

Name one of these many people.

> no libraries,

Put definitions in a file. Save.

> no structures,

http://www.forth200x.org/structures.html

> no decently built object system,

Forth has an abundance of object systems. Please, tell us about how
indecent they all are. You don't have to be exhaustive. Just list
off some of these indencies that you've noticed. I'll start: it is
indecent of objects.fs to rely on ALLOCATE at compile time; this
prevents it from being used in images or turnkey applications.

> it will be hard to duplicate the Pascal code.

Well it would be hard for anyone to duplicate code who is more
interested in hallucinating obstacles to action than he is in
putting finger to keyboard.

[Cecil Bayona]

On 8/6/2016 9:46 PM, hughag...@gmail.com wrote:
> On Saturday, August 6, 2016 at 7:28:45 PM UTC-7, Cecil - k5nwa wrote:
>> On 8/6/2016 6:58 PM, hughag...@gmail.com wrote:
>>> On Friday, August 5, 2016 at 10:16:08 PM UTC-7, Cecil - k5nwa wrote:
>>>> A long time ago I started using Borland Delphi for writing work related
>>>> and personal software but I could not afford the horribly expensive
>>>> database capable version at the time. I ended writing my own Self
>>>> Balancing B-Tree multi key database library, it was complex to figure it
>>>> out, and it took me a while to get it right, but once it was working I
>>>> would use it all over the place. It was very fast, it took little space,
>>>> and was very flexible so for years I used it for all sorts of tools and
>>>> applications.
>>>> ...
>> I been looking at the printed listing and I'm not sure it will be
>> practical to translate it to Forth, it makes heavy use of structures,
>> pointers to structures. With many people demanding that Forth continue
>> to stay in the 1970s, no libraries, no structures, no decently built
>> object system, it will be hard to duplicate the Pascal code.
>
> I don't see any problem with porting Pascal code into ANS-Forth --- just ignore the committee and their demand that we don't use structs --- I do fine in my novice-package ignoring them, and if you going to get your code into the novice-package you will have to ignore them too.
>
> I have a book on Pascal-S that supported nested functions. I know that Borland's Turbo-Pascal did not support nested functions though --- it was a trimmed-down non-standard Pascal --- I would assume that Borland's Delphi also did not support nested functions, but I never delved into Delphi very deeply.
>
> If Delphi Pascal is pretty comparable to Turbo Pascal, there should be no difficulty in porting to Forth. I hope that you do provide B-Trees to the novice-package --- I don't know enough about B-Trees to do this myself (without quite a lot of research) --- if you do it though, that would be pretty cool.
>

Delphi generated fairly good code, and it does allow defining a function
inside a function with access to the parents variables, those routines
were very fast with old PCs it could store and sort about 10 thousand
records per second, reading was even faster. I'm not sure that MySQL
could be that fast but I never tested it to see how efficient it was.

Fully functional quotations would really be useful in implementing the
conversion. I used to have some programs that would translate C or Turbo
Pascal code to Forth, and it was very thorough, most of the time the
generated code needed no changes, but I lost it a long time ago.

One wonders why so many are so against structures, and libraries, it's
hard to understand, maybe they have never used a good implementation of
these things to see how helpful they are in implementing and managing
software, in any case I live in the 21th Century not the 7th Century so
in the end I will do what I want.

>> Most likely
>> I will work eventually in an interface to MySQL and leave it at that, no
>> hurry there. I need MySQL capability eventually as I have several web
>> sites I maintain and they run on MySQL, I would like to build some
>> conversion programs to manipulate and modify MySQL databases used in
>> those sites.
>>
>> First I need to decide on what Forth system I will use for my desktops
>> computers, that is why I been playing with different Forth and Forth
>> like systems. I will be using two different Forths, one for desktops,
>> with decent library system and tools. The other a stripped down Forth
>> for embedded systems, I been using eForth for that purpose lately and
>> it's not bad for that purpose, there are plenty of versions available
>> for various CPUs, but I have sources to one version that is easily
>> migrated, I been using it with FPGA Forth CPUs and it's working well.
>
> Eventually I will bring out Straight Forth. I'm taking my time with that --- I have a lot to learn --- I want to avoid standardizing my ignorance, so I'm holding off on releasing it.
>
> In the meantime, just use VFX. My rquotations work on VFX and SwiftForth --- I could get them to work on any Forth system, most likely, but don't know until I try --- VFX generates pretty fast code, so it could be used for commercial programming.
>

I have VFX Standard and it works well, it's faster than SwiftForth which
I also own a copy with source. I don't have the source to VFX Standard
but I can't afford to buy the source, I have a copy as an item needed to
compile the ARM Pro Compiler for which I have the source. It's not the
evaluation copy so I can save copies of the modified system so
theoretically that could be my Desktop version but I wish I had the
source, one day Stephen Pelc will retire or an accident can happen, and
I will be in a pickle if there are problems, Windows is a moving target
and eventually it could cause problems. I hate to invest a lot of my
time to build the libraries to have the items I need and have no
guarantee that I will not have wasted my efforts.

A thought that often passes my mind is why not take eForth and flesh it
out a little more, then use it to create the libraries I want and have
full source to the darn thing. The version I have has a cross compiler
so one could generate a stand alone target system, for whatever CPU one
cares to modify it for but that is a lot of work, so I keep looking, but
having source is a item high on the list. eForth is my fallback system
if I can't find something with source that is workable.

--
Cecil - k5nwa

[Julian Fondren]

On Saturday, August 6, 2016 at 10:54:17 PM UTC-5, Cecil - k5nwa wrote:
> A thought that often passes my mind is why not take eForth and flesh it
> out a little more, then use it to create the libraries I want and have
> full source to the darn thing.

"Other people want to stay in the 1970s!"

"I've decided to ignore VFX, SwiftForth, iForth, Win32Forth, wina,
which all work after a fashion on Windows, so that I can start from
scratch with a Forth from the 1970s."

#JustCecilleThings

You two deserve each other.


-- Julian

[Paul Rubin]

Julian Fondren <julian....@gmail.com> writes:
> "I've decided to ignore VFX, SwiftForth, iForth, Win32Forth, wina,
> which all work after a fashion on Windows

Fwiw, Gforth also works on Windows, though it doesn't have any Windows
GUI calls built in. It runs in a dos box. Maybe that's enough for some
purposes.

[hughag...@gmail.com]

On Saturday, August 6, 2016 at 8:54:17 PM UTC-7, Cecil - k5nwa wrote:
> On 8/6/2016 9:46 PM, hughag...@gmail.com wrote:
> > I have a book on Pascal-S that supported nested functions. I know that Borland's Turbo-Pascal did not support nested functions though --- it was a trimmed-down non-standard Pascal --- I would assume that Borland's Delphi also did not support nested functions, but I never delved into Delphi very deeply.
> >
> > If Delphi Pascal is pretty comparable to Turbo Pascal, there should be no difficulty in porting to Forth. I hope that you do provide B-Trees to the novice-package --- I don't know enough about B-Trees to do this myself (without quite a lot of research) --- if you do it though, that would be pretty cool.
> >
> Delphi generated fairly good code, and it does allow defining a function
> inside a function with access to the parents variables, those routines
> were very fast with old PCs it could store and sort about 10 thousand
> records per second, reading was even faster. I'm not sure that MySQL
> could be that fast but I never tested it to see how efficient it was.
> Fully functional quotations would really be useful in implementing the
> conversion.

Well, Pascal-S had nested functions that only remained valid so long as the parent function remained in scope. Pascal-S allowed nested functions within nested functions, and it maintained a "display-pointer chain" so the lowest level function had access to all the local variables all the way up to the highest level function. This is very complicated! If your code relies on this, it is not going to be supported in Straight Forth. My quotations don't have locals of their own --- only the parent function has locals --- quotations can be nested, but there is no display-pointer chain because all of them just use the parent function's locals. Straight Forth is pretty simple, and the programs are expected to be pretty simple --- I don't actually know what all that complexity in Pascal-S was for --- I think it was just gratuitous complexity, like in a science-fair project, without any practical purpose. The rquotations that I wrote earlier for VFX and SwiftForth are pretty restrictive --- Straight Forth is more robust because it uses a fat-xt and so the quotation doesn't have to be executed at a certain level below the parent.

Try using the rquotations first under VFX. If that doesn't work, then I will get back to work on Straight Forth and put together a working system that you can use which will have the fat-xt quotations. If that doesn't work, then you are out of luck --- I don't intend Straight Forth to be any more complicated than this --- Straight Forth is intended to be about half the size of ANS-Forth with about twice the features, but nothing super-complicated.

Don't worry too much about VFX being closed-source --- you can always port your program to another system later on if necessary --- it is unlikely that you will be relying on any aspects of VFX that you will be unable to figure out how they work internally.

> A thought that often passes my mind is why not take eForth and flesh it
> out a little more, then use it to create the libraries I want and have
> full source to the darn thing. The version I have has a cross compiler
> so one could generate a stand alone target system, for whatever CPU one
> cares to modify it for but that is a lot of work, so I keep looking, but
> having source is a item high on the list. eForth is my fallback system
> if I can't find something with source that is workable.

I looked into eForth briefly, but I was stymied by the lack of documentation. I needed a reference document of the words in the system. I wasn't interested in learning the internal workings. I just wanted to be able to write basic programs, but I didn't know how to do things like reading text files, and I didn't have time to figure this out by delving into the source-code (I was getting paid to write a program; I couldn't spend days just figuring out how to read a text file). Because of this, I switched over to VFX.

It is possible that this documentation exists and I just couldn't find it. I can't believe anybody would ever use eForth if there wasn't documentation. Nothing on the website helped though. It is possible that I needed to buy one of their books, but I wasn't going to buy books randomly, so I sent an email asking which book I needed --- I never got any reply --- it is possible that C.H.Ting was already having health problems at that time that prevented him from continuing to support eForth.

If you have documentation for eForth, I would be willing to take a look at eForth again. Also, because I'm not getting paid now, I'm no longer under the gun, so I have more time to just explore the source-code. I might be able to make something of eForth yet.

In many ways, my goals with Straight Forth are similar to C.H.Ting's goals with eForth --- powerful and straightforward --- the exact opposite of ANS-Forth, which was a weak and ambiguous.

[Cecil Bayona]

Give me a couple of days, I'm in the middle of something not computer
related, I found several sources of documentation on eForth, enough to
be dangerous maybe, but better than a sharp stick in the eye. I have
several sources of documentation on eForth from C H Ting.
--
Cecil - k5nwa

[Paul Rubin]

Cecil Bayona <cba...@cbayona.com> writes:
> I found several sources of documentation on eForth, enough to
> be dangerous maybe, but better than a sharp stick in the eye. I have
> several sources of documentation on eForth from C H Ting.

Bill Muench's site is down but you can probably find his eforth pages in
the wayback machine. IIRC there was eforth itself, a metacompiler for
eforth, and a juiced-up version of eforth with more optimizations than
the stripped down version. Ting's version was different in that it was
bootstrapped from x86 assembly code, which he felt was easier for Forth
newbies to understand. Jeff Fox has some discussion of this idea on his
site someplace. I found the original eforth code to be quite readable,
but it is a very minimal Forth that uses a lot of clever tricks to be
tiny.

There is a C conversion here that is also simple:

http://chiselapp.com/user/tehologist/repository/compc/home

Mostly I don't understand quite what you're trying to do. Gforth is
reasonably fast and well documented, and it has plenty of creature
comforts (at least in the language implementation). So I'd probably use
it if the target machine is powerful enough for it. For smaller targets
there's lots of other choices such as FlashForth, Mecrisp, CamelForth,
etc. etc. in addition to eForth. Plus of course there are the
commercial implementations, that have real compilers, good support,
etc., at the expense of actual $$$$. And then there are variants like
oForth and 8th, that are more machine hungry than traditional Forth, but
that can make life easier in various ways.

[Cecil Bayona]

On 8/7/2016 3:06 AM, Paul Rubin wrote:
> Cecil Bayona <cba...@cbayona.com> writes:
>> I found several sources of documentation on eForth, enough to
>> be dangerous maybe, but better than a sharp stick in the eye. I have
>> several sources of documentation on eForth from C H Ting.
>
> Bill Muench's site is down but you can probably find his eforth pages in
> the wayback machine. IIRC there was eforth itself, a metacompiler for
> eforth, and a juiced-up version of eforth with more optimizations than
> the stripped down version. Ting's version was different in that it was
> bootstrapped from x86 assembly code, which he felt was easier for Forth
> newbies to understand. Jeff Fox has some discussion of this idea on his
> site someplace. I found the original eforth code to be quite readable,
> but it is a very minimal Forth that uses a lot of clever tricks to be
> tiny.
>

I'll look there but I often found that the Wayback machine doesn't
include downloads, which is OK if all you want is the web pages but you
never can tell, so I'll look.

> There is a C conversion here that is also simple:
>
> http://chiselapp.com/user/tehologist/repository/compc/home
>

Interesting version, I'll look at it. The eForth version I'm currently
using has a meta-compiler so it generates a native code version to run
on the target system, that is and advantage because of it's ability to
run faster in the target system.

> Mostly I don't understand quite what you're trying to do. Gforth is
> reasonably fast and well documented, and it has plenty of creature
> comforts (at least in the language implementation). So I'd probably use
> it if the target machine is powerful enough for it. For smaller targets
> there's lots of other choices such as FlashForth, Mecrisp, CamelForth,
> etc. etc. in addition to eForth. Plus of course there are the
> commercial implementations, that have real compilers, good support,
> etc., at the expense of actual $$$$. And then there are variants like
> oForth and 8th, that are more machine hungry than traditional Forth, but
> that can make life easier in various ways.
>

What am I trying to do? I wonder myself but what I'm looking for is a
simple Forth that is easy to understand and modify for some embedded but
mostly custom Forth CPUs. The version I'm using is not your standard
eForth version, it starts out as a Windows version of eForth, it has a
very simple meta-compiler, and assembler, and a source version of eForth
that uses very few machine language primitives, and mostly it's written
in eForth itself so it's easy to convert to other CPUs. It's from C H
Ting but it's not the Standard eForth you find out there, he uses it in
his FPGA projects because it's so easy to modify for new CPUs which is
what I'm working with.

GForth on the other hand is build for desktop use, not easily changeable
to other CPUs and quite large sot not suited for my purposes. I am aware
of other Forth such as meCrisp, and NoForth for embedded use, both of
these seem to be excellent at what they do, their issue is that adapting
them to use with custom FPGA CPUs is not trivial task compared to the
eForth version I mentioned above.

As for other desktop tools I did purchased a copy of 8th and I'm looking
at oForth for a special desktop project that require a lot of list and
text manipulation, hopefully one of them will work for that purposes.

There is a certain appeal to eForth because of it's simplicity, and
using it for custom CPUs and for the Desktop with a souped up version
would make life a little easier in the sense that for both targets one
is basically using similar versions of Forth.
--
Cecil - k5nwa

[hughag...@gmail.com]

On Sunday, August 7, 2016 at 1:06:29 AM UTC-7, Paul Rubin wrote:
> Mostly I don't understand quite what you're trying to do. Gforth is
> reasonably fast and well documented, and it has plenty of creature
> comforts (at least in the language implementation). So I'd probably use
> it if the target machine is powerful enough for it.

I have rquotations working under VFX and SwiftForth. I might be able to get them to work under Gforth, but I'm not enthusiastic about figuring out the internal workings of a C-based compiled. Getting rquotations to work under VFX was trivial because VFX is super-simple --- getting rquotations to work under SwiftForth was much more difficult because SwiftForth is grossly and pointlessly over-complicated --- getting rquotations to work under Gforth might be even worse. All in all, I'm not enthusiastic about disassembling other people's compilers, figuring out their over-complicated messy code, and fixing it so that it does something useful --- eForth doesn't have any documentation either --- at least eForth was designed to be small and simple though.

Everything I've seen of Anton Ertl's work indicates that he is not very good at Forth. For example:
1.) In Gforth he has FIND return different xt values for a given word depending upon what STATE is when FIND is called. If fixed this problem with my disambiguifiers, but he pretends that they don't exist.
2.) He wrote { (but called it {: to appease Leon Wagner) and he made the locals to the right of the | get initialized to an arbitrary value --- they should be initialized to zero.
3.) He is obsessed with making the Paysan-faked quotations standard in Forth-200x --- he has seen my rquotations, but he pretends that they don't exist --- he is obviously just a tool of Forth Inc. and he does what Leon Wagner tells him to do, even as it becomes increasingly stupid.

The last I checked, Gforth code was 1/2 the speed of SwiftForth code, and SwiftForth code was 1/4 the speed of VFX code, and VFX code was adequate for commercial programming but was limited to 32-bit (all desktop computers made this century are 64-bit). Anyway, Gforth is not "reasonably fast" --- I think Anton Ertl crippled Gforth so that it would not undermine the sales of SwiftForth --- he did this in exchange for Elizabeth Rather appointing him to be the chair-person of the Forth-200x committee.

[hughag...@gmail.com]

On Saturday, August 6, 2016 at 8:20:04 PM UTC-7, Julian Fondren wrote:
> On Saturday, August 6, 2016 at 9:28:45 PM UTC-5, Cecil - k5nwa wrote:

> > no structures,
>
> http://www.forth200x.org/structures.html
> ...

> > it will be hard to duplicate the Pascal code.
>
> Well it would be hard for anyone to duplicate code who is more
> interested in hallucinating obstacles to action than he is in
> putting finger to keyboard.

Julien Fondren is such a brown-noser! People such as this absolutely disgust me!

Anyway, I looked up that Forth-200x document that he provide a link to. Here is an excerpt:
-----------------------------------------------------------------------------
The name first implementation of STRUCT and END-STRUCT is not
difficult.

: STRUCT \ -- addr 0 ; -- size
CREATE HERE 0 0 , DOES> @ ;
: END-STRUCT \ addr n --
SWAP ! ; \ set size
: +FIELD \ n1 n2 "name" -- n3 ; addr -- addr+n1
CREATE OVER , + DOES> @ + ;

The name last implementations of STRUCT{ and }STRUCT are trivial
even for native code compilers:

: STRUCT{ \ -- 0
0 ;
: }STRUCT \ size "name" --
CONSTANT ;
: +FIELD \ n1 n2 "name" -- n3 ; addr -- addr+n1
CREATE OVER , + DOES> @ + ;

In both cases the definition of +FIELD is the same. Further words
that operate on types can all use +FIELD and so can be common to
both camps.

For many modern compilers, implementing +FIELD to provide efficient
execution requires carnal knowledge of the system.
-----------------------------------------------------------------------------

This looks familiar. This is just Stephen Pelc's code copied directly out of Pelc's book discussed in this thread --- the names have all been changed (we have STRUCT{ instead of STRUCT[ and +FIELD instead of FIELD and }STRUCT instead of ]STRUCT) --- the code is still grossly inefficient because it uses CREATE DOES> and it still has the problem of forcing the starting offset to be zero.

Most humorous is that last sentence:
"For many modern compilers, implementing +FIELD to provide efficient
execution requires carnal knowledge of the system."

This is not true! I have FIELD defined in the novice-package in ANS-Forth, and it provides efficient execution. Humorously, Stephen Pelc also has a version of FIELD written in ANS-Forth that provides equivalent efficiency to mine (although it is written differently), but the Forth-200x committee are standardizing his grossly inefficient version of FIELD that he most likely wrote 30 years ago when he was still learning Forth (isn't it true that that book of his was originally published about 30 years ago?).

I am disgusted by Forth-200x and their brown-nosers because they are obsessed with declaring themselves to be the sole arbiters of what is Standard, and insisting that they know everything there is to know about Forth, and insisting that people such as myself are obliged to learn from them but can never write Forth code of our own. The Forth-200x committee are arrogant jackasses --- I will continue to point out how grossly inefficient their code is when it is brought to my attention (as Julien Fondren brought it to my attention here) --- all of their code is grossly inefficient!

[Julian Fondren]

On Sunday, August 7, 2016 at 11:58:35 AM UTC-5, hughag...@gmail.com wrote:
> the code is still grossly inefficient because it uses CREATE DOES>

You keep saying "because it uses CREATE DOES>" , like CREATE DOES>
is inherently inefficient. It's only worse when you have a simple
constant -- like a field offset. If you're going to give a class of
words each their own private memory that will actually be mutated
or that will store more than a single cell, then CREATE DOES>
handles this neatly.

Although, with a word to indicate that some memory is fixed, an
optimizer remove the difference, replacing an inlined address and
fetch with whatever's already at that address.

( in a definition )
P.Y
<address> @ +
4 +

> and it still has the problem of forcing the starting offset to be zero.

The recommended "portable code" version makes the zero explicit and
easily changed. The 'forced' starting point can still be changed in
any case with code like

begin-structure list-of-frogs
list +
cell +field frog
end-structure

which might also look OK with +STRUCTURE as a synonym of +

> I am disgusted by Forth-200x and their brown-nosers because [blah blah blah]. The Forth-200x committee are arrogant jackasses

You, and now Cesyl, are constantly putting stupid libelous words in
other people's mouths. Why don't you pay attention to your own
words in your own mouth and shut up about other "so many people" who
"want to keep Forth in the 1970s" or who "want to prevent
cross-compilers" or who are "the sole arbiters" of things? Don't
you have anything to talk about except the horrible conspiracies of
Forth programmers?

In the real world, I've started to think that maybe the French
Revolution wasn't so bad of a thing. Previously I would've
described it as literally the worst event that ever happened to any
civilization, ever. But there are so many political and media
personalities who so clearly deserve to be butchered in job lots or
served to the guillotine. Hell, Canada is ruled now by someone who
is more Marie Antoinette than she actually was. But then I go check
on what's up with Forth - a relaxing, non-political subject - and
here you are speaking as if the *nothing* that anyone has ever done
to you is why you can't have nice things. Be serious for a bit.


-- Julian


"Why are you doing this to me?!"

"Because it's 2016."

[Håkan Thörngren]

On Sunday, August 7, 2016 at 9:33:51 AM UTC-7, hughag...@gmail.com wrote:

> 1.) In Gforth he has FIND return different xt values for a given word depending upon what STATE is when FIND is called. If fixed this problem with my disambiguifiers, but he pretends that they don't exist.

I am interested in the best way to handle this case. If you refer to,
say IF, outside compilation, it does not have a a defined semantics in
that case. What should happen if you try to FIND it?

I can on the top of my head think of three ways to deal with it:

1. You FIND it, but realize you are in the wrong mode and give an
error. This is what I believe Gforth does.

2. You arrange your search order and word lists in such a way that if
you try to FIND such word in a state where it has no defined
semantics, it will not find it.

3. You find it anyway and let the word decide what to do, you
essentially put the responsibility on the word.

I would like to understand the pros and cons of these approaches, or
even if there are further ways. For the moment I feel most appealed by
(2), it makes seems quite clean and simple.
(I have not reflected on the actual complexities of arranging the
search order, word lists and relation to STATE to uphold it).
I like to understand this better.

> 2.) He wrote { (but called it {: to appease Leon Wagner) and he made the locals to the right of the | get initialized to an arbitrary value --- they should be initialized to zero.

I really like to see { being uses rather than {:, the whole community
should not suffer because one vendor at some point did what looks to
be the wrong choice.

> 3.) He is obsessed with making the Paysan-faked quotations standard in Forth-200x --- he has seen my rquotations, but he pretends that they don't exist --- he is obviously just a tool of Forth Inc. and he does what Leon Wagner tells him to do, even as it becomes increasingly stupid.

Regarding quotations I would very much like to see that we go for
allowing quotations to access variables of their parents, provided we
can do it using a generic mechanism.
I do not want a special case implementation like you promote, it is
too fragile.

As I understand it, what you propose is that a HOF need a environment,
the quotation cannot have it, but are given its parent
environment. What happens if the programmer uses a word that creates
an environment? It will trash the environment of the HOF (unless you
are maintaining double environment pointers).
Also consider that words invoked from the quotation may not create an
environment today, but someone may come along later and change it and
suddenly it does. It is trap waiting to go off.

You can always argue that quotations are simple so it won't be a
problem. I say that if you put a useful mechanism in hands of people,
they are bound to find good creative uses of it that you did not
foresee. You are basically preventing this and making the system
fragile.

Double environment pointers would solve it, but I would rather go for
allowing inner words to access environments of their parent and
grand-parents, as well as having an environment of their own.

In such case we need some kind of closure (or semi-closure) xt. It
would need to carry the xt together with the environment pointer of its
immediate parent. Once this is in place, it is actually easy to access any
local in any surrounding environment.

At compile time you find the word to be a local in a surrounding
parent environment. For example, you find that it is two steps away
and have index 8. Then you compile that information in as a
environment lookup. (All environments used in such context need an
extra slot to carry a pointer to its immediate parent.)
At run-time, you just follow the pointers to previous environments
back 2 times and offset into that record.

[hughag...@gmail.com]

On Sunday, August 7, 2016 at 11:31:18 AM UTC-7, Håkan Thörngren wrote:
> On Sunday, August 7, 2016 at 9:33:51 AM UTC-7, hughag...@gmail.com wrote:
>
> > 1.) In Gforth he has FIND return different xt values for a given word depending upon what STATE is when FIND is called. If fixed this problem with my disambiguifiers, but he pretends that they don't exist.
>
> I am interested in the best way to handle this case. If you refer to,
> say IF, outside compilation, it does not have a a defined semantics in
> that case. What should happen if you try to FIND it?
>
> I can on the top of my head think of three ways to deal with it:
>
> 1. You FIND it, but realize you are in the wrong mode and give an
> error. This is what I believe Gforth does.
>
> 2. You arrange your search order and word lists in such a way that if
> you try to FIND such word in a state where it has no defined
> semantics, it will not find it.
>
> 3. You find it anyway and let the word decide what to do, you
> essentially put the responsibility on the word.
>
> I would like to understand the pros and cons of these approaches, or
> even if there are further ways. For the moment I feel most appealed by
> (2), it makes seems quite clean and simple.
> (I have not reflected on the actual complexities of arranging the
> search order, word lists and relation to STATE to uphold it).
> I like to understand this better.

Look at my novice-package (I can email the latest version to you). I have disambiguifiers. These cause words such as IF to become immediate (in ANS-Forth they can be immediate or non-immediate, and in VFX they weirdly are non-immedate) --- the words work fine when executed in compilation mode --- the words abort with an error message when executed in interpretation mode.

> Regarding quotations I would very much like to see that we go for
> allowing quotations to access variables of their parents, provided we
> can do it using a generic mechanism.
> I do not want a special case implementation like you promote, it is
> too fragile.

I agree that my rquotations are fragile, but this was the best I could do given VFX and SwiftForth.

I don't think the fragility is as bad as you believe. Just remember the four rules:
1.) The rquotation must be called with REX rather than EXECUTE.
2.) Only a HOF can use REX.
3.) A HOF can not call another HOF.
4.) A HOF must have local variables.

> In such case we need some kind of closure (or semi-closure) xt. It
> would need to carry the xt together with the environment pointer of its
> immediate parent. Once this is in place, it is actually easy to access any
> local in any surrounding environment.

This is how Straight Forth works. It has a "fat xt." In Straight Forth the cells are 64-bit, but the addresses are all 32-bit. A fat-xt is a 64-bit struct that contains the 32-bit cfa and the 32-bit pointer to the parent function's local-frame.

The fat-xt can be passed around and used without following the four rules mentioned above for rquotations --- the only limitation is that the parent function still has to be in scope when the quotation is executed --- I have a method for checking this and aborting with a helpful error message if the parent function is not in scope, rather than just blindly access a local-frame that no longer exists.

[hughag...@gmail.com]

On Sunday, August 7, 2016 at 5:05:56 AM UTC-7, Cecil - k5nwa wrote:
> ...I'm looking

> at oForth for a special desktop project that require a lot of list and

> text manipulation...

What does oForth provide in regard to linked lists and strings that I don't provide in the novice package? LIST.4TH and STRING-STACK.4TH pretty much cover those two subjects, I think.

[Paul Rubin]

Cecil Bayona <cba...@cbayona.com> writes:
> The eForth version I'm currently using has a meta-compiler so it
> generates a native code version to run on the target system

Oh that's interesting--I don't think I've seen it. Is it online?

> What am I trying to do? I wonder myself but what I'm looking for is
> a simple Forth that is easy to understand and modify for some embedded
> but mostly custom Forth CPUs.

Do you mean a resident Forth that will run on a softcore CPU of your own
design? Or a cross-compiler like the one Bernd uses for his b16? If
you want a tiny resident Forth, eForth seems like a good starting point.
For cross-compilation, eForth is pretty limited unless you extend it a
lot, so you might want to use something more featureful.

> There is a certain appeal to eForth because of it's simplicity, and
> using it for custom CPUs and for the Desktop with a souped up version
> would make life a little easier in the sense that for both targets one
> is basically using similar versions of Forth.

I'll be interested in seeing the souped up version when you have it.
The version I played with was imho too limited for comfort, compared to
other Forths out there.

[Cecil Bayona]

I'm not sure but oForth have Listbuffers, mutable list of items with
your standard features, get, save, insert, copy,and delete items or
entire list, plain list are immutable so they are not as useful but
still usable to hold non-changing data such as conversion patterns. I'm
not an expert so take the information on this reply with a grain of salt.

I'm not familiar enough with your novice package enough to tell you the
difference between your software and these two Forth like programs. Next
week I have allotted some time to compare oForth, 8th, and VFX with your
library to see which are more usable, and efficient.

8th does not have list that I can find, but it has arrays of containers
that can be used for a similar purpose, it's different in the sense that
they are "containers" which are just pointers and can hold any type of
object including other containers, copying, of an item means copying the
pointer not the data so it's more efficient when manipulating a lot of
containers. That scheme is not efficient when using integers but can be
efficient with complex containers.

8th is also quite different from Forth in other ways, I have not found
Builds, Does or any compiler words to define words with a compile time
and a different run time behavior that would be rather limiting, but I'm
not familiar enough to be 100% confident that it is so, I could have
missed it somehow.
--
Cecil - k5nwa

[Cecil Bayona]

On 8/7/2016 2:35 PM, hughag...@gmail.com wrote:

> This is how Straight Forth works. It has a "fat xt." In Straight Forth the cells are 64-bit, but the addresses are all 32-bit. A fat-xt is a 64-bit struct that contains the 32-bit cfa and the 32-bit pointer to the parent function's local-frame.
>
> The fat-xt can be passed around and used without following the four rules mentioned above for rquotations --- the only limitation is that the parent function still has to be in scope when the quotation is executed --- I have a method for checking this and aborting with a helpful error message if the parent function is not in scope, rather than just blindly access a local-frame that no longer exists.
>

In Delphi when you define a function inside a function, it passes a
pointer to the parents environment, so the function has access to the
parents variables, and that environment contains a pointer to it's
parents environment, so you could access the grand-parents variables
also or further back the chain. I have never tried it other than
accessing the parents variables but the possibility is there. In couple
of cases that proved rather handy, I didn't know they were closures but
I did used them in a couple of cases when manipulating complex data
structures in the BT+ Library, it cut down on the number of parameters
being passed since I could access the parents data and change it.
--
Cecil - k5nwa

[hughag...@gmail.com]

On Sunday, August 7, 2016 at 2:02:49 PM UTC-7, Cecil - k5nwa wrote:
> On 8/7/2016 3:01 PM, hughag...@gmail.com wrote:
> > On Sunday, August 7, 2016 at 5:05:56 AM UTC-7, Cecil - k5nwa wrote:
> >> ...I'm looking
> >> at oForth for a special desktop project that require a lot of list and
> >> text manipulation...
> >
> > What does oForth provide in regard to linked lists and strings that I don't provide in the novice package? LIST.4TH and STRING-STACK.4TH pretty much cover those two subjects, I think.
> >
> I'm not sure but oForth have Listbuffers, mutable list of items with
> your standard features, get, save, insert, copy,and delete items or
> entire list, plain list are immutable so they are not as useful but
> still usable to hold non-changing data such as conversion patterns. I'm
> not an expert so take the information on this reply with a grain of salt.
>
> I'm not familiar enough with your novice package enough to tell you the
> difference between your software and these two Forth like programs. Next
> week I have allotted some time to compare oForth, 8th, and VFX with your
> library to see which are more usable, and efficient.

You may also want to look at Factor. I was impressed by how Factor uses one data-structure for pretty much everything. This is the "sequence." It is possible to build other data-structures, but for the most part sequences are used unless you have some special need that sequences don't support. Having one data-structure like this makes the programs consistent and easy to read --- this was my inspiration for LIST.4TH --- I use lists for pretty much everything in the novice-package.

[Cecil Bayona]

On 8/7/2016 3:55 PM, Paul Rubin wrote:
> Cecil Bayona <cba...@cbayona.com> writes:
>> The eForth version I'm currently using has a meta-compiler so it
>> generates a native code version to run on the target system
>
> Oh that's interesting--I don't think I've seen it. Is it online?

Yes one version is available with the code to work on the Ting's ep16 CPU.

>
>> What am I trying to do? I wonder myself but what I'm looking for is
>> a simple Forth that is easy to understand and modify for some embedded
>> but mostly custom Forth CPUs.
>
> Do you mean a resident Forth that will run on a softcore CPU of your own
> design? Or a cross-compiler like the one Bernd uses for his b16? If
> you want a tiny resident Forth, eForth seems like a good starting point.
> For cross-compilation, eForth is pretty limited unless you extend it a
> lot, so you might want to use something more featureful.

The meta compiler provided will compile the source that is used to
create a target version of eForth that runs in the FPGA target softcore
CPU. Quite useful, you run native eForth on your target CPU.

>
>> There is a certain appeal to eForth because of it's simplicity, and
>> using it for custom CPUs and for the Desktop with a souped up version
>> would make life a little easier in the sense that for both targets one
>> is basically using similar versions of Forth.
>
> I'll be interested in seeing the souped up version when you have it.
> The version I played with was imho too limited for comfort, compared to
> other Forths out there.
>

It will be a while, I'm doing research to see if something else out
there would be a better choice, eForth is my fallback position , it does
advantages in that the same basic Forth would be used in softcores and
the desktop, with the desktop being clearly more capable.
--
Cecil - k5nwa

[hughag...@gmail.com]

On Sunday, August 7, 2016 at 1:55:12 PM UTC-7, Paul Rubin wrote:
> For cross-compilation, eForth is pretty limited unless you extend it a
> lot, so you might want to use something more featureful.

I have said many times that a cross-compiler needs these features:
1.) LITERAL is vectored so the built-in outer-interpreter can be used and when it encounters a number in a TARG colon word it compiles that number into the target memory rather than the host memory.
2.) The ability to take an xt and determine the following attributes:
what vocabulary it is in
immediate or non-immediate
smudged or not smudged
smudge-ready or not smudge-ready
3.) The ability to take an xt and modify those attributes.
4.) CONTEXT and CURRENT have to work like they did in Forth-83.
5.) FIND has to work correctly.

I have fixed ANS-Forth so #4 and #5 are true now. There is nothing I can do in ANS-Forth to obtain #1 #2 and #3 however --- these have all been banned in the ANS-Forth Standard.

Would it be easier to modify eForth to provide these features? I would expect so!

Other than this, I don't really need a "featureful" Forth system to write a cross-compiler --- I do need it to be 32-bit though, as there isn't enough memory in a 16-bit system to both hold the target image and the cross-compiler --- I can do this in 16-bit UR/Forth though, by allocating a 64KB segment to be the target image, and using ES to address it. I started MFX in the 16-bit UR/Forth, but then had to switch to the 32-bit UR/Forth because MFX itself became too big to fit in the 64KB DS segment; also, the MiniForth needed 64KW (128KB) target images for both code and data memory --- all in all, MFX was just too big to run under 16-bit UR/Forth.

[Håkan Thörngren]

On Sunday, August 7, 2016 at 2:11:36 PM UTC-7, Cecil - k5nwa wrote:

> In Delphi when you define a function inside a function, it passes a
> pointer to the parents environment, so the function has access to the
> parents variables, and that environment contains a pointer to it's
> parents environment, so you could access the grand-parents variables
> also or further back the chain. I have never tried it other than
> accessing the parents variables but the possibility is there. In couple
> of cases that proved rather handy, I didn't know they were closures but
> I did used them in a couple of cases when manipulating complex data
> structures in the BT+ Library, it cut down on the number of parameters
> being passed since I could access the parents data and change it.
> --
> Cecil - k5nwa

They are not real closures. To implement a real closure you need to
allocate environments on a heap so that they can survive when the
parent function goes out of scope. You may also have a pointer from
the top-most parent environment to the global environment.
This implies some kind of mechanism that can reclaim memory for
environments when they finally go out of scope, which usually means of
a garbage collector, probably not a feature you want in Forth.

In any case, just having fake-closures can be useful, as you
apparently found out from using Delphi.

[Håkan Thörngren]

On Sunday, August 7, 2016 at 12:35:36 PM UTC-7, hughag...@gmail.com wrote:

> Look at my novice-package (I can email the latest version to you). I have disambiguifiers. These cause words such as IF to become immediate (in ANS-Forth they can be immediate or non-immediate, and in VFX they weirdly are non-immedate) --- the words work fine when executed in compilation mode --- the words abort with an error message when executed in interpretation mode.

Yes, feel free to send it to me. I downloaded it a couple of days ago,
but it was probably an older version. Also tell me where the
disambiguifiers are, there are many files in that package.

Maybe you want to put it on some code hosting site?

[Håkan Thörngren]

On Sunday, August 7, 2016 at 3:03:12 PM UTC-7, hughag...@gmail.com wrote:
> I have said many times that a cross-compiler needs these features:
> 1.) LITERAL is vectored so the built-in outer-interpreter can be used and when it encounters a number in a TARG colon word it compiles that number into the target memory rather than the host memory.
> 2.) The ability to take an xt and determine the following attributes:
> what vocabulary it is in
> immediate or non-immediate
> smudged or not smudged
> smudge-ready or not smudge-ready
> 3.) The ability to take an xt and modify those attributes.
> 4.) CONTEXT and CURRENT have to work like they did in Forth-83.
> 5.) FIND has to work correctly.
>
> I have fixed ANS-Forth so #4 and #5 are true now. There is nothing I can do in ANS-Forth to obtain #1 #2 and #3 however --- these have all been banned in the ANS-Forth Standard.

I am not sure I follow you here.

By ANS-Forth, do you mean Forth-94? What about EuroForth?

I worked on a cross compiler, but got the semantics for different
modes wrong. I will need to restart that work at some point, but now I
am a little bit too busy with other things.

This is why I want to figure out if I should go for search-order based
compilation state, to make FIND only find compiling words during
compilation. I do not feel comfortable with double-xts at the moment.

I do not understand in what way the standard prevent you from making a
cross compiler? Conceptionally what I did was to have a record of
low-level compiling primitives, one for host compilation and one for
target cross-compilation. The words that change between compilation
modes simply swap these records. Then the low-level standard words in
Forth that compile to memory simply invoke primitives in the active
compiler record.

I just put whatever functions I needed in that record.

[Elizabeth D. Rather]

There are a number of Forth cross-compilers that represent extensions of
ANS/ISO Forth, and have been for over 20 years. You may find a
discussion of standard Forth cross-compilers here:
http://newsgroups.derkeiler.com/Archive/Comp/comp.lang.forth/2007-06/msg00283.html

Both FORTH, Inc. and MPE offer cross-compilers based on this model,
although both companies have improved their offerings since these
documents were written. Still, the basic principles are there. The
articles provide a good philosophical framework. You may also try and
exercise the cross compilers from FORTH, Inc. and MPE using free
evaluation versions to get a feel for the technology as well as the
"look and feel" (which is not described in the documents). The download
from FORTH, Inc. includes complete documentation. I assume the MPE one
does, too.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[Anton Ertl]

=?UTF-8?B?SMOla2FuIFRow7ZybmdyZW4=?= <hth...@gmail.com> writes:
>On Sunday, August 7, 2016 at 9:33:51 AM UTC-7, hughag...@gmail.com wrote:
>

>> 1.) In Gforth he has FIND return different xt values for a given word dep=
>ending upon what STATE is when FIND is called. If fixed this problem with m=

>y disambiguifiers, but he pretends that they don't exist.
>
>I am interested in the best way to handle this case. If you refer to,
>say IF, outside compilation, it does not have a a defined semantics in
>that case. What should happen if you try to FIND it?
>
>I can on the top of my head think of three ways to deal with it:
>
>1. You FIND it, but realize you are in the wrong mode and give an
> error. This is what I believe Gforth does.

Just check it out yourself.

There is no provision in the standard for FIND giving an error on
valid input.

Here is what Gforth 0.7 does:

: c-if c" if" ; ok
c-if find ok
.s <2> 139790204771072 1 ok
drop ok
xt-see
: compile-only-error
-14 throw ; ok

So when you FIND IF in interpretation state, you get the xt of a word,
that, when executed, produces an error ("Interpreting a compile-only
word").

In the meantime, we have changed compile-only words to produce a
warning instead of an error, so in the development version of Gforth
interpreted IF just behaves like compiled IF (i.e., it's just an
immediate word), but also gives a warning, and when you FIND IF, you
get the same xt in both STATEs; when you EXECUTE that, it behaves just
like compiled IF (no warning):

: c-if c" if" ; ok
c-if find ok
.s <2> 140215597006432 1 ok
drop xt-see
: IF [']
?branch compile, >mark ; ok

However, the bigger problem is words like (FILE wordset) S" that have
valid interpretation semantics and valid compilation semantics, that
are neither default compilation semantics nor immediate compilation
semantics. There Gforth's FIND produces different xts in compilation
state and interpretation state:

create c-s" 2 c, 's' c, '"' c, ok
c-s" find .s <2> 140215597015472 1 ok
drop xt-see
noname :
34 parse save-mem ; ok
: ]find[ ] find postpone [ ; ok
c-s" ]find[ .s <2> 140215597015568 1 ok
drop xt-see
noname :
34 parse POSTPONE SLiteral ; ok

>2. You arrange your search order and word lists in such a way that if
> you try to FIND such word in a state where it has no defined
> semantics, it will not find it.

That's the cmForth way, and is probably what the ANS Forth TC had in
mind when they wrote that FIND can return different results in
different STATEs.

>3. You find it anyway and let the word decide what to do, you
> essentially put the responsibility on the word.

If the word decides, that is STATE-smartness. The problem with that
is that the word decides based on the STATE at run-time, and if the
STATE at run-time differs from the STATE where the word appeared, the
result is often not what the programmer had in mind. See
<https://www.complang.tuwien.ac.at/papers/ertl98.ps.gz> for a longer
discussion on that topic.

>I would like to understand the pros and cons of these approaches, or
>even if there are further ways. For the moment I feel most appealed by
>(2), it makes seems quite clean and simple.

As long as you don't implement the search order, yes, it probably is.
But this approach has not been picked up by many Forth
implementations, and I think the reason is that it stops being simple
once you also want to implement a search order.

- 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 2016: http://www.euroforth.org/ef16/

[Anton Ertl]

=?UTF-8?B?SMOla2FuIFRow7ZybmdyZW4=?= <hth...@gmail.com> writes:
>By ANS-Forth, do you mean Forth-94?

In the reality where Hugh Aguilar lives, Forth-2012 has not been
released, so in that reality, the current standard is Forth-94 and is
still referred to as ANS Forth.

> What about EuroForth?

EuroForth is a yearly conference on Forth, not a standard.

[Anton Ertl]

Julian Fondren <julian....@gmail.com> writes:
>On Sunday, August 7, 2016 at 11:58:35 AM UTC-5, hughag...@gmail.com wrote:
>> the code is still grossly inefficient because it uses CREATE DOES>
>
>You keep saying "because it uses CREATE DOES>" , like CREATE DOES>
>is inherently inefficient. It's only worse when you have a simple
>constant -- like a field offset. If you're going to give a class of
>words each their own private memory that will actually be mutated
>or that will store more than a single cell, then CREATE DOES>
>handles this neatly.

Well, if it's 2 cells, as in 2CONSTANT, the required memory access can
still be inefficient:

: 2const create swap , , does> 2@ ;
1. 2constant x1
1. 2const x2
: foo1 x1 d+ ;
: foo2 x2 d+ ;
see foo1
see foo2

Compiling and decompiling this on VFX produces:

FOO1
( 080C0B60 8B5500 ) MOV EDX, [EBP]
( 080C0B63 83C201 ) ADD EDX, 01
( 080C0B66 83D300 ) ADC EBX, 00
( 080C0B69 895500 ) MOV [EBP], EDX
( 080C0B6C C3 ) NEXT,
( 13 bytes, 5 instructions )

FOO2
( 080C0B90 8B5500 ) MOV EDX, [EBP]
( 080C0B93 0315340B0C08 ) ADD EDX, [080C0B34]
( 080C0B99 131D300B0C08 ) ADC EBX, [080C0B30]
( 080C0B9F 895500 ) MOV [EBP], EDX
( 080C0BA2 C3 ) NEXT,
( 19 bytes, 5 instructions )

Two additional memory accesses, and 6 additional bytes in the code.

>Although, with a word to indicate that some memory is fixed, an
>optimizer remove the difference, replacing an inlined address and
>fetch with whatever's already at that address.

Yes, that is one of the approaches considered (and possibly
implemented in VFX and/or iForth) for getting rid of this
inefficiency.

The standard way is to let 2const define a colon definition:

: 2const ( n1 n2 -- ; run-time -- n1 n2 )
2>r : 2r> postpone 2literal postpone ; ;

The disadvantage is that each child consumes more memory than the
children of CREATE...DOES> words.

Another approach is to define an optimizer for the newly-defined word:

\ works on the development version of Gforth
: 2const ( n1 n2 -- )
create 2,
[: 2@ ;] set-does>
[: >body 2@ postpone 2literal ;] set-optimizer ;

(SET-OPTIMIZER is present in VFX under the misleading name
SET-COMPILER, but you also have to work around the absence of 2, and
SET-DOES>).

#1. 2const x ok
: foo x ; ok
simple-see foo
$7F8871BE8A90 lit
$7F8871BE8A98 <$1>
$7F8871BE8AA0 lit
$7F8871BE8AA8 <$0>
$7F8871BE8AB0 ;s ok

[franck....@gmail.com]

Le dimanche 7 août 2016 23:02:49 UTC+2, Cecil - k5nwa a écrit :
> I'm not sure but oForth have Listbuffers, mutable list of items with
> your standard features, get, save, insert, copy,and delete items or
> entire list, plain list are immutable so they are not as useful but
> still usable to hold non-changing data such as conversion patterns. I'm
> not an expert so take the information on this reply with a grain of salt.
>

Yes.

Items into listbuffers are not limited to integers.
They can also be others objects, or even other lists.
In that case, the listbuffer holds a pointer to the object. For instance :

ListBuffer new
12 over add
12.3 over add
4 seq over add
"abcdef" over add
[ "abc" , "def" , "ghi" ] over add
.s
[1] (ListBuffer) [12, 12.3, [1, 2, 3, 4], abcdef, [abc, def, ghi]]
ok
#size over map .s
1] (List) [1, 1, 4, 6, 3]
2] (ListBuffer) [12, 12.3, [1, 2, 3, 4], abcdef, [abc, def, ghi]]
ok

But you are right : for small integers, the listbuffer (and lists) holds
the integer value, not a pointer to this integer.

Franck
http://www.oforth.com

[Anton Ertl]

an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:

I forgot two more, as yet unimplemented (or inefficiently
implemented) approaches:


CONST-DOES> is designed for exactly this problem. You specify how
many stack items you want to pass from the word creation time to the
run-time, as follows:

: 2const ( n1 n2 "name" -- )
2 0 const-does> ( -- n1 n2 )
;

... u1 u2 CONST-DOES> creates a word <name>, consumes u1 cells and u2
floats at creation time. At <name> run-time, it pushes these u1 cells
and u2 floats on the respective stacks, in the original order.

You can find the proposal and a paper about it at:
<http://www.forth200x.org/const-does.html>
http://www.complang.tuwien.ac.at/anton/euroforth/ef00/ertl00.pdf

The reference implementation does not get rid of the memory accesses,
though, and is also inefficient in other ways, but an efficient
implementation is not hard.


Another, unimplemented approach (but totally natural for people
familiar with lamda-calculus-inspired languages) would be this:

: 2const {: n1 n2 -- :}
create does> drop n1 n2 ;

Of course, if you pass locals in this way, there is no need to pass
data in memory, so there is no need to have a DOES> that pushes an
address, and also no need for separating CREATE from DOES> (there is
no commaing going on between CREATE and DOES>), so one can have a word
CREATE> used as follows:

: 2const {: n1 n2 -- :}
create> n1 n2 ;

Is this implementable? There have been discussions about closures
with explicity memory management. In the present case, the memory for
the closure would be allocated with ALLOT, and a syntax for that might
be ALLOT[: ... ;]. With that, and a word <CREATE that takes a
closure, this would become

: 2const {: n1 n2 -- :}
allot[: n1 n2 ;] <create ;

I think that an implementation of that is within reach. The cost: in
addition to n1 and n2, the trampoline for the closure (2-4 cells,
depending on the implementation) would need to be stored. And to
avoid memory accesses, there is quite a bit of compiler sophistication
necessary: The compiler would have to notice that there are no TO
accesses to n1 and n2, and would have to inline the closure into
calls, resolving the (memory) access to the locals during compilation
and thus optimizing the references to n1 and n2 in the inlined closure
into literals.

All this complexity seems more appropriate for Haskell than for Forth,
so while this is cute, I think that the SET-OPTIMIZER approach is more
Forth-like.

[Cecil Bayona]

Thanks for the extra information, I should have been more clear, in that
the ListBuffer could hold not just integers, I just mentioned "items"
and didn't specify what the items were.

ListBuffer is a very powerful and useful feature in oForth, quite handy
for use with applications that require complex data structures and its
manipulation. That is one of many powerful features in oForth that are
helpful in writing applications. The only negative I would say about
oForth is the documentation, alas a failing of many programs, otherwise
oForth seems to have been built with a purpose, which is to efficiently
write applications for the desktop computer.

I have two pieces of software that I been interested in lately, and they
both have complex data storage and manipulation, One is a BT+ database
program to be converted from Delphi Pascal, the second a complex Text
Macro Processing Tool. In trying to figure out what software tools I
will use, so I will be trying out some test programs in 8th, oForth, and
VFX Forth with Hugh's library. I will be looking at ease of
implementation, and the speed as in both software tools, speed is vital
in order for them to be usable.

Today I started the process, I'm trying to figure out a test which will
be representative of the task that will need to be done in writing those
two applications, yet be as simple as possible. Unfortunately my brain
seems fixated in a Delphi Pascal solution, I sometimes find it hard to
think in terms of Forth when complex programs need to be created, when
thinking about complex task my brain wants to switch to Delphi Pascal on
auto-pilot, I'm hoping to fix that with these two projects.
--
Cecil - k5nwa

[m...@iae.nl]

On Monday, August 8, 2016 at 11:43:13 AM UTC+2, Anton Ertl wrote:
> Julian Fondren <julian....@gmail.com> writes:
> [..]

[..]


Did you check what happens when you use foo1 and foo2?

FORTH> : 2const create swap , , does> 2@ ; ok
FORTH> 1. 2constant x1 ok
FORTH> 1. 2const x2 ok
FORTH> : foo1 x1 d+ ; ok
FORTH> : foo2 x2 d+ ; ok
FORTH> see foo1
Flags: TOKENIZE, ANSI
: foo1 [trashed] D+ ; ok
FORTH> see foo2
Flags: TOKENIZE, ANSI
: foo2 x2 D+ ; ok
FORTH> : test 22. foo1 33. foo2 d+ d. ; ok
FORTH> see test
Flags: ANSI
$01322F80 : test
$01322F8A mov rbx, $01322A48 qword-offset
$01322F91 add rbx, #33 b#
$01322F95 mov rdi, $01322A40 qword-offset
$01322F9C adc rdi, 0 b#
$01322FA0 add rbx, #23 b#
$01322FA4 adc rdi, 0 b#
$01322FA8 push rbx
$01322FA9 push rdi
$01322FAA jmp D.+10 ( $012395BA ) offset NEAR

Doubles are not well optimized in iForth -- the carry poses
specialized problems for register allocation.

-marcel

[JennyB]

A different approach: for every possible kind of Constant there is an equivalent literal. A constant is simply a memoised literal; it does a get-from-memory instead of a parse.

Therefore, a new kind of constant should be defined something like a new kind of recognizer. You need to specify the GET action and the PUT action.

Something like this:

: CONSTANT ['] @ ['] LITERAL make-const , ;
: 2CONSTANT ['] 2@ ['] 2LITERAL make-const 2, ;

[Anton Ertl]

11. foo2 d. 4294967307

Obviously not:-)

Ok, the correct definition of 2CONST is:

: 2const create , , does> 2@ ;

With that SEE FOO2 gives:

FOO2
( 080C0B30 8B5500 ) MOV EDX, [EBP]
( 080C0B33 0315040B0C08 ) ADD EDX, [080C0B04]
( 080C0B39 131D000B0C08 ) ADC EBX, [080C0B00]
( 080C0B3F 895500 ) MOV [EBP], EDX
( 080C0B42 C3 ) NEXT,

( 19 bytes, 5 instructions )

Also 2 memory accesses and 6 bytes more than FOO1.

[Anton Ertl]

m...@iae.nl writes:
>Doubles are not well optimized in iForth -- the carry poses
>specialized problems for register allocation.

You are not alone with this problem. See
<2016May2...@mips.complang.tuwien.ac.at> for an example of how
bad code generated by gcc for 256-bit addition looks, and my
explanation why.

[hughag...@gmail.com]

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 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."

What this means is that giving the string C" IF" to FIND is an ambiguous condition. IF is a Forth word however and it has an xt --- C" IF" is valid input --- so, it is obvious that Anton Ertl is lying.

Section 3.4.4. explains what will happen:
----------------------------------------------------------------------------
Possible actions on an ambiguous condition
When an ambiguous condition exists, a system may take one or more of the following actions:
– ignore and continue;
– display a message;
– execute a particular word;
– set interpretation state and begin text interpretation;
– take other implementation-defined actions;
– take implementation-dependent actions.
The response to a particular ambiguous condition need not be the same under all circumstances.
----------------------------------------------------------------------------

There are two ways to write a cross-compiler. One (the easy way) is to use the built-in outer-interpreter. This won't work in ANS-Forth however because LITERAL is not vectored and so when you encounter a literal number the outer-interpreter will compile it into host memory --- you want LITERAL to be vectored so you can change it for TARG words to compile the literal number into target memory, then change it back for HOST words to do what it usually does.

The second way (the somewhat more complicated way) is to write your own outer-interpreter. This won't work in ANS-Forth however because FIND considers looking up most of the words in the system (such as IF etc.) to be an ambiguous condition. I have actually fixed FIND however with my disambiguifiers --- ironically, Anton Ertl invented the disambiguifiers himself way back in 2009 --- now however, Anton Ertl refuses to acknowledge the existence of the disambiguifiers.

This second way, btw, is still problematic because QUIT isn't vectored in ANS-Forth. This means that if you abort with an error then you get dumped back into the built-in outer-interpreter rather than back to your custom outer-interpreter.

[hughag...@gmail.com]

On Monday, August 8, 2016 at 12:10:22 AM UTC-7, Elizabeth D. Rather wrote:
> There are a number of Forth cross-compilers that represent extensions of
> ANS/ISO Forth, and have been for over 20 years.

Saying that Forth cross-compilers are "extensions of ANS/ISO Forth" is the same as saying that Forth cross-compilers are necessarily non-standard --- it is not possible to write a cross-compiler in ANS-Forth --- ANS-Forth was crippled to prevent common Forth programmers from writing cross-compilers in competition with Forth Inc. and MPE who rely heavily on undocumented non-standard features in their compilers to write their cross-compilers.

[m...@iae.nl]

On Tuesday, August 9, 2016 at 8:25:40 AM UTC+2, Anton Ertl wrote:
> m...@iae.nl writes:
> >Doubles are not well optimized in iForth -- the carry poses
> >specialized problems for register allocation.
>
> You are not alone with this problem. See
> <2016May2...@mips.complang.tuwien.ac.at> for an example of how
> bad code generated by gcc for 256-bit addition looks, and my
> explanation why.

Such links appear not to work for Google anymore. In what group is that?

-marcel

[Anton Ertl]

One site that offers Message-Id search is <http://al.howardknight.net/>

>In what group is that?

comp.arch.

[Anton Ertl]

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. I don't think there
are any Forth systems that produce an error when performing

: c-if c" if" ;
c-if find

Of course, some people find it surprising that

c-if find drop execute

produces an error in Gforth 0.7, but errors produced during execution
of xts returned by FIND are no rarity.

[hughag...@gmail.com]

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.

Earlier, I provided a list of what is needed for a cross-compiler. Let me slightly upgrade that list:

1.) LITERAL is vectored so the built-in outer-interpreter can be used and when it encounters a number in a TARG colon word it compiles that number into the target memory rather than the host memory.

2.) QUIT is vectored so the user can write his own outer-interpreter if he wants, and if it aborts on an error then control will go back to his outer-interpreter rather than to the built-in outer-interpreter (because ABORT and ABORT" call QUIT internally).
3.) The ability to take an xt and determine the following attributes:

what vocabulary it is in
immediate or non-immediate
smudged or not smudged
smudge-ready or not smudge-ready

4.) The ability to take an xt and modify those attributes.
5.) CONTEXT and CURRENT have to work like they did in Forth-83.
6.) FIND has to work correctly. The words in the standard have to be defined as being immediate or non-immediate. Words that have traditionally been immediate (everything requiring a disambiguifier in ANS-Forth) will be defined as immediate.

My primary goal with Straight Forth is to allow Forth programmers to write cross-compilers using a standard Forth system. As it currently stands, ANS-Forth has been sabotaged to prevent cross-compilers from being written (because this would be competition against Forth Inc. and MPE). It is possible to write a cross-compiler in various Forth systems, but each system has to be disassembled and the cross-compiler writer will need to rely on carnal knowledge. I did this with UR/Forth when I wrote MFX, but not a lot of carnal knowledge was necessary as UR/Forth was already pretty good out of the box. Modern Forth systems, such as VFX are a lot bigger than UR/Forth and hence disassembling them to obtain the needed carnal knowledge is more time-consuming and difficult. We shouldn't have to disassemble Forth systems though, because this is a waste of time. Also, the cross-compilers are not portable but obviously become vendor-specific due to relying on carnal knowledge. The goal with Straight Forth is just that we have a Standard that supports cross-compilers and does so in a straightforward manner that is well documented. People can write cross-compilers and they can be ported to any Straight Forth system. The cross-compiler itself will not be standardized in Straight Forth because there are many valid ways to write a cross-compiler (the most important choice is to either use the built-in outer-interpreter or write your own outer-interpreter, but there are other choices as well). There is room for creativity in writing a cross-compiler and it is not my business to tell people how to write their cross-compilers. Straight Forth only serves as a common host for these cross-compilers, making them possible.

I don't understand why Straight Forth is controversial. Other than Leon Wagner and Stephen Pelc, who is opposed to common Forth programmers writing cross-compilers? I wrote MFX for the MiniForth processor in 1994/1995 --- everybody on comp.lang.forth treats me like a criminal for doing this --- they howl: "That is not the Forth Way!!!" WTF???

Straight Forth can be a pretty simple Forth Standard --- about 1/2 the size of ANS-Forth and 1/8 the size of Forth-200x --- I'm adding a few features, such as quotations, that aren't related to cross-compilation, but Straight Forth is still pretty simple and straightforward --- a super-simple Forth Standard seems like a good thing to me, because Forth was traditionally super-simple (only with ANS-Forth did Forth become complicated, ambiguous and difficult or impossible to understand).

Most Forth programmers, including myself, originally got interested in Forth (rather than C) because of these reasons:
1.) Forth is simple and easy to understand. There is no syntax. The outer-interpreter is a short and straightforward function. Forth is to C as Go is to Chess.
2.) Forth is extensible. For example, in Forth structs can start with any offset, whereas in C they have to start with zero. As another example, a Forth system can be extended to generate code for a different processor (cross-compilation) using the built-in outer-interpreter, whereas in C a new compiler has to be written from scratch with its own super-complicated outer-interpreter.
3.) Forth is interactive. We can debug individual functions from the command-line (a REPL to use the Lisp term), whereas in C an entire program has to be compiled into an executable and then single-stepped through with a debugger.

I see no reason why Forth-200x and Straight Forth can't coexist as incompatible Standards --- their goals are completely different so they can't be combined into one Standard --- the Forth community can just diverge into two groups each with their own Standard and each with their own take on what Forth is:
1.) Forth-200x --- mind-numbingly complicated and utterly useless and opposed to general-purpose data-structures
2.) Straight Forth --- super-simple and useful as the host for a cross-compiler and supportive of general-purpose data-structures

[Julian Fondren]

On Wednesday, August 10, 2016 at 9:56:36 PM UTC-5, hughag...@gmail.com wrote:
> I don't understand why Straight Forth is controversial.

It isn't. You argue for it; nobody argues against it. You develop your
definition of it; nobody disputes your definitions. An example of a
controversial thing would be ANS Forth: people don't understand it (or the the
role of a 'standard' even) or regard it as malign or unnecessary or degenerate;
others defend it against all of those charges, and try to explain what
standards are for. Not as much anymore now that you've settled on it just
being malign, but more interesting attacks and defences are clf history.

Go ahead and do your Straight Forth. But nobody cares. Nobody is 'howling'
anything. If you desire opposition so much, well, maybe you'll get some when
you actually produce it. One can hope.


-- Julian

[Anton Ertl]

hughag...@gmail.com writes:
>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.170=
>0):=3D
>> > "Interpretation semantics for this word are undefined." The ANS-Forth d=
>ocu=3D
>> >ment has a section (4.1.2) with the ominous heading: "Ambiguous Conditio=
>ns.=3D
>> >" One of the many ambiguous conditions is: "attempting to obtain the exe=
>cut=3D
>> >ion token, (e.g., with 6.1.0070 ', 6.1.1550 FIND, etc.) of a definition =
>wit=3D
>> >h undefined interpretation semantics."
>>=20

>> 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. =20
>
>Well, I'm glad that you are admitting that FIND in ANS-Forth is broken. I w=
>ould 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

FIND does not occur in that posting.

I dimly remember you pointing out that ambiguous condition at another
occasion, though, but obviously that has not stuck in my memory
enough, or I would not have written the sentence above.

[hughag...@gmail.com]

ANS-Forth is terrible as a standard because it is rife with ambiguity. I have said this 100 times --- I'm pretty sure that you can dimly remember me saying this!

One ambiguity is that words in the ANS-Forth Standard aren't defined to be immediate or non-immediate, so in some ANS-Forth systems IF and semicolon etc. are immediate and in other ANS-Forth systems (VFX) they are non-immediate. I said this is "one ambiguity" but it is actually over 50 ambiguities because that is how many words in ANS-Forth have this problem --- that is how many disambiguifiers are needed to fix the problem --- I have these disambiguifiers in the novice-package.

Another ambiguity is that the definition of FIND (section 6.1.1550) includes this sentence:
"For a given string, the values returned by FIND while compiling may differ from those returned while not compiling."
In general, whenever you are reading the ANS-Forth document and you encounter the word "may," then you are in trouble!

In Gforth, FIND returns different values for a given string depending upon what STATE is when FIND is executed. This was mind-blowing for me in 2009 (when I wrote my LC53 encryption-cracking program in ANS-Forth) --- I had never expected such an abomination given my years of programming in Forth-83 --- this abomination is ANS-Forth standard though! Also, in Gforth, tick aborts when it encounters these words --- this was very unexpected to me, because I would have assumed that tick and FIND worked comparably (normally tick calls FIND internally) --- in Gforth they behave completely differently given the same string.

In VFX all of these words (such as IF and semicolon etc.) that were immediate traditionally, are now non-immediate (in Gforth they are still immediate). This was mind-blowing for me in 2009 --- I had never expected such an abomination given my years of programming in Forth-83 --- this abomination is ANS-Forth standard though! In VFX all of these non-immediate words are special-cased internally within COMPILE, so they execute at compile-time like immediate words and generate code for run-time. In VFX tick and FIND return an xt for these words, but when the xt is given to EXECUTE (whether STATE is compiling or interpreting), the system aborts. So, the xt is an unexecutable execution-token. Mind-blowing!!!

For many years (from 2009 until 2015) I believed that FIND was completely broken in ANS-Forth and that there was no way to write a cross-compiler in which I write my own outer-interpreter. Then, I figured out the solution during the course of this thread:
https://groups.google.com/forum/#!topic/comp.lang.forth/oXXQAGDKP7w%5B1-25%5D
This was when I wrote the disambiguifiers. Now FIND in ANS-Forth is fixed! All of the ambiguity is gone! All of those words are now immediate (including in VFX where they were non-immediate). For all of those words FIND returns one xt value (including in Gforth where FIND returned different xt values depending upon what STATE was when FIND executed). For all of those words the xt value can be executed during the compilation of a colon word and it will work properly just like any immediate word should (including in VFX where all of these xt values would abort the system when executed during the compilation of a colon word).

This is why they are called "disambiguifiers" --- all of that mind-blowing ambiguity is removed and all of these 50-some words work correctly and consistently --- what is not to love about disambiguifiers???

The reason why the Forth-200x committee hates disambiguifiers is because the disambiguifiers allow the common Forth programmer to write his own outer-interpreter, which was effectively illegal in ANS-Forth --- a custom outer-interpreter can be used as the basis for a cross-compiler --- the Forth-200x committee is dedicated to preventing common Forth programmers from writing cross-compilers in competition against Forth Inc. and MPE, hence they hate the disambiguifiers.

My first-ever ANS-Forth program was LowDraw.4th which is now in the novice-package. This program worked out pretty well and I felt confident that I could learn ANS-Forth easily given my experience with Forth-83. My second-ever ANS-Forth program was the LC53 encryption-cracking program which used MACRO: (I wrote MACRO: in MFX originally when I was employed at Testra, and MFX was pretty-much Forth-83). This worked under SwiftForth so I made the code public, but it did not work under Gforth and so I was heavily criticized in that thread mentioned above for being a bad ANS-Forth programmer. This was when I doubted that I would ever become an ANS-Forth programmer. Now in 2016 nobody on comp.lang.forth has changed their mind on this subject --- they continue to criticize me for being a bad ANS-Forth programmer --- it has become obvious that I will always be a bad ANS-Forth programmer, which is why I'm now working on the Straight Forth standard to replace ANS-Forth.

The whole point of Straight Forth is that there is no ambiguity, and everything makes sense, and the language definition is short and simple --- this is what is needed for a standard that supports cross-compilers --- you have to have a solid foundation to write a cross-compiler!

[Stephen Pelc]

On Thu, 11 Aug 2016 13:16:42 -0700 (PDT), hughag...@gmail.com
wrote:

>In VFX tick and FIND return=
> an xt for these words, but when the xt is given to EXECUTE (whether STATE =

>is compiling or interpreting), the system aborts.

Bollocks!

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

Version: 4.72 [build 3552]
Build date: 24 July 2016

Free dictionary = 7545678 bytes [7368kb]


' ' execute words ok-1
. 4282148 ok
' words . 4282148 ok

>The whole point of Straight Forth is that there is no ambiguity, and everyt=

>hing makes sense, and the language definition is short and simple

Ah, but Straight Forth doesn't exist ...

Stephen

--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[hughag...@gmail.com]

On Thursday, August 11, 2016 at 4:36:05 PM UTC-7, Stephen Pelc wrote:
> On Thu, 11 Aug 2016 13:16:42 -0700 (PDT), hughag...@gmail.com
> wrote:
>
> >In VFX tick and FIND return=
> > an xt for these words, but when the xt is given to EXECUTE (whether STATE =
> >is compiling or interpreting), the system aborts.
>
> Bollocks!
>
> VFX Forth for Windows IA32
> © MicroProcessor Engineering Ltd, 1998-2015
>
> Version: 4.72 [build 3552]
> Build date: 24 July 2016
>
> Free dictionary = 7545678 bytes [7368kb]
>
>
> ' ' execute words ok-1
> . 4282148 ok
> ' words . 4282148 ok

Your example code above is just a big steaming pile of bollocks. This is meaningless.

The bug in VFX has already been covered in this thread that I mentioned above as being where I figured out the disambiguifiers:

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

: my-if [ ' if ] literal execute ; immediate ok
: ttt ( flag -- ) my-if ." true" else ." false" then ;
Err# -14 ERR: Attempt to interpret a compile only definition.
-> : ttt ( flag -- ) my-if ." true" else ." false" then ;

The xt (execution token) of IF can't be executed in VFX --- just like I said! IF is actually non-immediate in VFX, which is an abomination --- just like I said!

Now, here is the disambiguifier to fix the bug in VFX:

: if state @ 0= abort" *** no interpretation semantics for: IF ***" postpone if ; immediate

IF is redefined ok

Now we try again:

: my-if [ ' if ] literal execute ; immediate
MY-IF is redefined ok

: ttt ( flag -- ) my-if ." true" else ." false" then ; ok

TTT now compiles correctly! Yay! Lets test it:

1 ttt true ok
0 ttt false ok

The bug in VFX has been fixed with the disambiguifier! In the novice-package I now have disambiguifiers that fix all the broken words in VFX --- these are the same words that are broken in Gforth (except broken in a different way) --- the disambiguifiers fix all of the ANS-Forth systems and makes them consistent.

It is obvious to me that you are just straight out lying when you claim that FIND in ANS-Forth is not broken. You want FIND in ANS-Forth to be broken in order to prevent common ANS-Forth programmers from writing their own outer-interpreter, because you don't want common ANS-Forth programmers to write cross-compilers in competition with MPE.

[hughag...@gmail.com]

On Thursday, August 11, 2016 at 4:36:05 PM UTC-7, Stephen Pelc wrote:

> On Thu, 11 Aug 2016 13:16:42 -0700 (PDT), hughag...@gmail.com
> wrote:
>
> >In VFX tick and FIND return=
> > an xt for these words, but when the xt is given to EXECUTE (whether STATE =
> >is compiling or interpreting), the system aborts.
>
> Bollocks!

Well, I looked up "bollocks" in Urban Dictionary.

I now claim that my disambiguifiers are the "dog's bollocks" because they fix the problem in VFX of words that traditionally were immediate (such as IF semicolon etc.) being non-immediate and having a non-executable execution-token (it aborts when given to EXECUTE whether in compilation mode or interpretation mode).

They also fix problem in Gforth of these words aborting the system when ticked. They also fix the problem in Gforth of FIND returning different xt values for these words depending upon what STATE is when FIND is executed.

They also fix the problem in ANS-Forth that these words given to tick or FIND is in an "ambiguous condition" (meaning that pretty much anything can happen, including reformatting the hard-disk, and that is considered to be Standard) --- this is why VFX and Gforth and SwiftForth all behave differently, but are all ANS-Forth Standard compliant --- the disambiguifiers not only work on VFX, Gforth and SwiftForth, but also on any ANS-Forth compliant system that may be written in the future (this is because they rely on POSTPONE internally which, unlike tick and FIND, isn't ambiguous).

Disambiguifiers! The dog's bollocks! The only people who don't like disambiguifiers are those who do like ambiguity...

[endlessboo...@gmail.com]

On Tuesday, August 2, 2016 at 12:33:47 PM UTC-4, JUERGEN wrote:
> It took longer than expected, but as Stephen allowed me to reformat his book for publication on amazon, it had to be finished - came out today https://www.amazon.co.uk/dp/B01JIWVB5S or your local amazon.
> After Chuck Moore - Early Years https://www.amazon.de/dp/B00JZI64U8
> and Chuck Moore - Programming a Problem Oriented Language https://www.amazon.de/dp/B00K3PIYX2
> leading to the Forth Lite Tutorial - https://www.amazon.de/dp/B00L0F32Q8
> we have 4 now.
> Enjoy Stephen's eBook.

what apps did you make with forth?

[JUERGEN]

ENDLESS POO is just a troll it seems - drunk? annot typ

[endlessboo...@gmail.com]

hey eurotrash hush up
usa economy is way better and standard of living
do some pushups and build some muscle you woman


now back to the book
is it free online

will there ever be a forth wikibook?

will there be a web cgi tool for gforth?

[endlessboo...@gmail.com]

On Saturday, August 13, 2016 at 3:18:51 PM UTC-4, JUERGEN wrote:

https://www.youtube.com/watch?v=xLInwHuCZM8

[JUERGEN]

Does anybody know who She/He is? A danger to the environment and himself.
The last company that I notified about such a crasy consultant as this is supposedly, stopped paying as not wanting to be affiliated - they called it work ethics.

in His own words, copied from there LISP:

On Saturday, July 2, 2016 at 9:09:53 AM UTC-4, Wasell wrote:
> On Fri, 1 Jul 2016 10:54:18 -0700 (PDT), in article <5a3f07f9-5b22-4430-aab2-
> 5d8be4...@googlegroups.com>, endlessboo...@gmail.com wrote:
> >
> > On Friday, July 1, 2016 at 12:02:42 PM UTC-4, George Neuner wrote:
> > > On Fri, 1 Jul 2016 08:17:48 -0700 (PDT),
> > > endlessboo...@gmail.com wrote:
> > >
> > > >write a how to program in lisp wikibook that defines its terms before using them
> > >
> > > define "define"
> >
> > the ayn rand sense
> >
> > for example, if you say object
> >
> > define it before use it
> >
> > define any word not in the very very common usage
> >
> > any technical term
> >
> > for lisp
> > closures
> > macros
> > variable
> > value
> > procedure
> > etc
> >
> > define the word before you use it
> >
> > otherwise smart reader like me locks up
> > not knowing what the hell you mean
>
> A large part of the problem, in your particular case, is that you're an idiot.

fuk u
>
> Every book, article, tutorial, or conversation in general, requires that you
> know a number of terms, to begin with. You, Gavino, are too fucking uneducated
> to know these terms, even though you should know them, given your claimed
> background.
>
fuk u

> You're also too fucking stupid to _understand_ these terms, even when they're
> explained to you in excruciating detail. And they have been explained to you,
> over and over and over again.
>
I am way smarter than you.
The books don't explain things thats the problem.
Nothing has been explained to me over and over, shithead.

> Moreover, you're too fucking lazy to even try to learn a programming language.

fuk you
I am massively hardworking and have a non government job, do you?
shithead?
what website did you create?
crickets lol!!

fuktard!!
> You failed to learn the most basic parts of Forth.
fuk u moron

You haven't (as far as I
> have seen) written a single line of neither Common Lisp, nor Scheme.
I have posted many lines of code shithead.
shithead!!!
The only
> thing you have ever managed to produce is a trivial one-liner in AWK. (And it's
> a pretty safe bet that that one-liner was copied from somewhere.)
>
fuck you shithead!!!!
the one liner is all thats needed!! and I dont see your lisp version you shit talking do nothing commy!!

post some code or a working website you have up powered by lisp right now or shut the fuk up!!! you shit talking goblin who insults your betters!

> Also, you regurgitate the same imbecilic questions a bazillion times, even
> after they've been answered, as if the very repetition of a question could
> change its truthful answer.

I never get answer, maybe because shitheads like you are too insecure to write "I dont know"
ya fucking shitbag!!

>
> And would you, for the love of Odin, learn to spell the word "like"! It's not
> "liek"! Really, it isn't!
>


typing is a pleb skill!!!
besides this is the net not a government school english class you fucking twat!
> "Smart reader", my ass!
>
fuuuk you commy!! I am way beyond your iq!!!! proven by fact you attack me not respond to the problem or post code solution!!
fuck off you drive by shit talker!!

End of quote.
I know it is strong language, sorry, but just a quote from the CL LISP to give a picture

[hughag...@gmail.com]

One of the things that trolls do is post the exact same message repeatedly. By my count, you have posted this one-liner 6 times now:
https://groups.google.com/forum/#!searchin/comp.lang.forth/endless$20poo%7Csort:date
So, you've mastered ctrl-C and ctrl-V --- please tell us what else you know about computers!

You are a salesman for Stephen Pelc: http://mpeforth.com/about.htm
"Juergen is our marketing and sales person promoting MPE Forth and MPE Consultancy Services."
Gavino makes a good point that you haven't written any programs in Forth --- so this is a battle between non-programmers calling each other non-programmers --- way to impress the world on the Forth community's ability to program!

That book is just sales for MPE. Stephen Pelc wrote it, not to educate people on Forth, but just to promote himself as an expert on Forth. The code provided is grossly inefficient and badly designed:

0 constant [struct \ -- 0 ; start
\ Start a structure definition, returning zero as
\ the initial offset.
: field \ offset n -- offset+n ; addr -- addr+offset
\ When defining a structure, a field of size n starts
\ at the given offset, returning the next offset. At
\ run time, the offset is added to the base address.
create
over , + \ lay offset and update
does>
@ + \ addr offset to address
;
: struct] \ offset -- ; -- size ; end
\ End a structure definition by naming it.
constant
;

His book makes no mention of inheritance. The reader goes away with the idea that the Forth community doesn't know what inheritance is.

[JUERGEN]

HATE POST - Hugh Aguilar Typical verbal Excrement - and this is new

[Cecil Bayona]

WOW, extreme anger displayed there, I can understand someone being angry
but this example takes the cake, wise is the advise to not reply until
one has calmed down and taken some deep breaths. c.l.f is just full of
surprises, the Internet encourages this kind of behavior because most
people would not act this way in front of someone else for fear of
getting your teeth knocked out, but in the Internet there is no
repercussions to bad behavior.



--
Cecil - k5nwa

[lawren...@gmail.com]

On Sunday, August 7, 2016 at 11:58:14 AM UTC+12, hughag...@gmail.com wrote:
> What is sad about this, is that Forth has better support for
> code-libraries than C does. In C, a struct has to start on offset zero.

That’s not how data abstraction is supposed to work. With an abstract data type, you have no knowledge of the internal data layout at all, you have to use library-provided accessors to do everything.

Consider a Cairo drawing context <https://www.cairographics.org/manual/cairo-cairo-t.html>. Somewhere in there is a reference to a surface <https://www.cairographics.org/manual/cairo-cairo-surface-t.html>. But the only way to get it is via cairo_get_target <https://www.cairographics.org/manual/cairo-cairo-t.html#cairo-get-target>.

This way, the internals of the objects can change in a few version of the library, and your existing code will still work, without even needing to be recompiled.

And that works with straight C. Can Forth say the same?

[hughag...@gmail.com]

Well, in LIST.4TH I have SEQ that inherits from LIST. A person writing code for SEQ doesn't need to know what fields are in LIST. All he needs to know are what methods are available for LIST.

If you look at my code supporting SEQ you will find functions that use EACH and LINK and various other methods belonging to LIST --- you will not find any functions that use .FORE which is the field being inherited from LIST --- only functions such as EACH and LINK etc. that support LIST will access the .FORE field.

To ask if Forth OOP supports abstraction seems like a funny question --- abstraction is the whole point of OOP --- if an OOP system doesn't support abstraction, then it is not an OOP system.

I don't think that OOP in C supports abstraction as well as OOP in Forth --- C has serious problems, not the least of which being that STRUCT forces the first offset to be zero, and the type-checking gets in the way so a pointer to a child object can't be treated as a pointer to the parent object without a typecast being done, but after the typecast has been done then SIZEOF doesn't work correctly anymore.

[lawren...@gmail.com]

On Wednesday, August 17, 2016 at 5:41:00 AM UTC+12, hughag...@gmail.com wrote:
> I don't think that OOP in C supports abstraction as well as OOP in Forth ---
> C has serious problems, not the least of which being that STRUCT forces the
> first offset to be zero, and the type-checking gets in the way so a pointer
> to a child object can't be treated as a pointer to the parent object without

> a typecast being done...

None of which has anything to do with data abstraction, as I pointed out in my example--one of many more I can offer if you like.

[hughag...@gmail.com]

On Tuesday, August 16, 2016 at 10:41:00 AM UTC-7, hughag...@gmail.com wrote:
> On Monday, August 15, 2016 at 8:33:49 PM UTC-7, lawren...@gmail.com wrote:
> > With an abstract data type, you have no knowledge of the internal data layout at all, you have to use library-provided accessors to do everything.

> > ...

> > This way, the internals of the objects can change in a few version of the library, and your existing code will still work, without even needing to be recompiled.
> >
> > And that works with straight C. Can Forth say the same?
>
> Well, in LIST.4TH I have SEQ that inherits from LIST. A person writing code for SEQ doesn't need to know what fields are in LIST. All he needs to know are what methods are available for LIST.
>
> If you look at my code supporting SEQ you will find functions that use EACH and LINK and various other methods belonging to LIST --- you will not find any functions that use .FORE which is the field being inherited from LIST --- only functions such as EACH and LINK etc. that support LIST will access the .FORE field.

It is not clear to me what you mean by "abstract data type" --- apparently not the same thing that I mean.

Maybe you are referring to virtual functions. These I would provide similar to Oberon --- they are just W fields in the object that contain the xt of the function that does it (they get filled in by the constructor) --- I wouldn't have a VMT like in C++ (I doubt there is any C system that has a VMT either). I still think that Forth is better than C because C's type-checking gets in the way --- pointers to functions in C involve complicated declarations --- also, you often have to use a void pointer because your function (such as a HOF) doesn't know the type of the function-pointer, but later on you use a typecast to get back to the actual function-type in the code that will actually use the function-pointer.

Anyway, this discussion should be moved to here:
https://groups.google.com/forum/#!topic/comp.lang.forth/cH-pGXhBCfE

Our current thread is just a salesman of MPE promoting a book written by Stephen Pelc which makes no mention of OOP or inheritance at all and provides a rather useless and inefficient way to define structs --- there is no evidence to indicate that Stephen Pelc knows what inheritance is --- him and his salesman don't want their thread hijacked with a discussion of OOP code that is useful! The goal of that book that Stephen Pelc wrote was to present Forth as being a toy language --- similar to "Starting Forth" but without the cartoons.

[Brad Eckert]

On Monday, August 15, 2016 at 10:34:32 AM UTC-7, Cecil - k5nwa wrote:
> WOW, extreme anger displayed there, I can understand someone being angry
> but this example takes the cake, wise is the advise to not reply until
> one has calmed down and taken some deep breaths. c.l.f is just full of
> surprises, the Internet encourages this kind of behavior because most
> people would not act this way in front of someone else for fear of
> getting your teeth knocked out, but in the Internet there is no
> repercussions to bad behavior.

Such delusions are the price of a free society, which I suppose is why freedom never lasts. The current unmoderated forum filterable for trolls seems to be working okay once you get used to it. In the meanwhile, Hugh is a very informative case study in abnormal psychology. Why pass up such a fine specimen?

[hughag...@gmail.com]

On Wednesday, August 17, 2016 at 10:08:45 PM UTC-7, Brad Eckert wrote:
> Such delusions are the price of a free society, which I suppose is why freedom never lasts. The current unmoderated forum filterable for trolls seems to be working okay once you get used to it. In the meanwhile, Hugh is a very informative case study in abnormal psychology. Why pass up such a fine specimen?

You are trying to bait me --- hoping to get an emotional response in which I tell you to "go fuck yourself" or some such thing --- I see this kind of baiting all the time from the ANS-Forth cult members.

[WJ]

JUERGEN wrote:

> HATE POST - Hugh Aguilar Typical verbal Excrement - and this is new

You give the impression that you are such an airhead that you
cannot even compose a sentence.

Are you related to Gavino?

[JUERGEN]

Unfortunately you cannot grasp the context of the last posts here yet or you just give a shit - and so I do feel sorry for you,

and NO

[hughag...@gmail.com]

Well, I read Bernd Paysan's article on Mini-OOF:
https://bernd-paysan.de/mini-oof.html

In there, he says:
-----------------------------------------------------------------------------
Note: this early binding means that the xt you have assigned to the method may not have non-default compilation semamtics applied with SET-COMPILER (e.g. in VFX Forth). Example: You want to perform the execution semantics of IF in a method

:noname ( -- if-sys ) postpone IF ; some-class defines if-method
is the only portable way to achive this. If you have a mix of interpretation and compilation semantics, like with S", achieving a deliberate selection portable may even be more difficult:

:noname state @ >r postpone [ ['] s" execute r> IF ] THEN ; class defines xxx
will most likely work on all systems.
-----------------------------------------------------------------------------

Well, that looks familiar! Bernd Paysan (Forth-200x committee member) is on the verge of figuring out how to write a disambiguifier. As I said before, disambiguifiers were originally invented by Anton Ertl (Forth-200x committee chair-person) in 2009. Later on, in the "Bug in VFX" thread mentioned above, I figured out that disambiguifiers could solve the problem with FIND --- and so I now have all the disambiguifiers in the novice-package.

Stephen Pelc says "Bollocks!" to me, implying that I'm lying about FIND is broken in ANS-Forth. Yet, it is obvious that both Anton Ertl and Bernd Paysan are aware of the fact that FIND is broken in ANS-Forth --- they are working around the problem with disambiguifiers --- they are working around the problem in the same way that I am!

So, why doesn't Stephen Pelc say "Bollocks!" to Anton Ertl and Bernd Paysan? He doesn't do this because he doesn't want to undermine the credibility of the Forth-200x committee. Instead he says "Bollocks!" to me --- he feels confident in doing this because he knows that all of the Forth-200x sycophants will support him in this --- the Forth-200x sycophants love to fling vulgar insults at anybody who criticizes ANS-Forth or Forth-200x; that is what Forth-200x is all about.

I said above:
----------------------------------------------------------------------------

It is obvious to me that you are just straight out lying when you claim that FIND in ANS-Forth is not broken. You want FIND in ANS-Forth to be broken in order to prevent common ANS-Forth programmers from writing their own outer-interpreter, because you don't want common ANS-Forth programmers to write cross-compilers in competition with MPE.

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

This is the truth!

ANS-Forth is a cult. Forth Inc. and MPE purposely crippled ANS-Forth so that it would not be useful for writing a cross-compiler in competition with Forth Inc. and MPE. They are doing the same with Forth-200x now. They rely entirely on sycophants to support them --- the sycophants just do this because it is fun to be a big expert in programming --- with ANS-Forth and Forth-200x they don't have to learn how to program, but all that is required of them is loyalty to the Forth-200x committee.

[hughag...@gmail.com]

On Thursday, August 11, 2016 at 8:49:47 PM UTC-7, hughag...@gmail.com wrote:

> On Thursday, August 11, 2016 at 4:36:05 PM UTC-7, Stephen Pelc wrote:
> > On Thu, 11 Aug 2016 13:16:42 -0700 (PDT), hughag...@gmail.com
> > wrote:
> >
> > >In VFX tick and FIND return=
> > > an xt for these words, but when the xt is given to EXECUTE (whether STATE =
> > >is compiling or interpreting), the system aborts.
> >
> > Bollocks!

> ...

> It is obvious to me that you are just straight out lying when you claim that FIND in ANS-Forth is not broken. You want FIND in ANS-Forth to be broken in order to prevent common ANS-Forth programmers from writing their own outer-interpreter, because you don't want common ANS-Forth programmers to write cross-compilers in competition with MPE.

I was looking through some old Jeff Fox emails and I found this:
------------------------------------------------------------------
It is nearly impossible to get Elizabeth to say anything
that isn't marketing language. But eventually I got [her] to
say simply, "FORTH Inc. supports the standard and the
standard supports FORTH Inc."
------------------------------------------------------------------

This is what I have been saying --- ANS-Forth was always just a marketing gimmick from Forth Inc. to make it appear that Forth Inc. sets the standard for the entire Forth community --- and ANS-Forth was purposely crippled to trap the Forth community in a pitfall of incompetence, but if anybody writes Forth code competently then they get denounced for being non-standard. This is primarily why my MFX was ignored in the late 1990s --- the ANS-Forth crowd could denounce it because it was non-standard --- and the C crowd could denounce it because it was "Forth" which was considered to be a synonym for "stupid" due to ANS-Forth having made stupidity the standard or Forth in 1994.

[Cecil Bayona]

On 8/28/2016 7:33 PM, hughag...@gmail.com wrote:

> I was looking through some old Jeff Fox emails and I found this:
> ------------------------------------------------------------------
> It is nearly impossible to get Elizabeth to say anything
> that isn't marketing language. But eventually I got [her] to
> say simply, "FORTH Inc. supports the standard and the
> standard supports FORTH Inc."
> ------------------------------------------------------------------

"ANS Forth a guide to alternate realities" is a book that could deal
with all these possibilities and alternate realities. Soon to be
available at a store near you, in Hardback and eBook versions available
soon.

Buy a dozen with a 20% discount, and give it as a gift to your enemies,
and relatives!
--
Cecil - k5nwa

[hughag...@gmail.com]

The whole idea of a book is just a big joke --- Forth has been dead since 1994 --- maybe I should use this title:
"ANS-Forth --- the zombie programming language --- no flicker of intelligence, but still lurching forward"