Is there a free version of Forth that uses the exact same words as "Starting Forth" on Forth Inc.'s site?

[Darin Murphy]

Hey everybody!

It's been a very, very long time since I posted on this site. Was
away from Forth for 6 months trying to go to UOPeople, which
wasn't what I expected. I started back up with Forth in Dec 2016
and nearly finished with "Starting Forth". I like taking my time
to make sure I understand things very well and have already made
a much of small trivial programs outside of the book, including
one that was a tiny rogue game using a only 1 dimensional array
as the screen buffer. It was a blast!

Anyway, I've stumbled upon an issue with the book and was
wondering if someone knew where I can find a free forth that
works with my Raspberry Pi and uses all of the same exact words
as the ones in "Starting Forth" on Forth Inc.'s site? I
understand it's a tall order, but just thought I'd ask. I've
already tried 4e4th, which is a great little Forth that runs on a
MSP430, but it's so small that it's missing a lot of words (i.e.,
missing all of Chapter 3 words). I've also tried gForth which has
a crazy amount of words, and has gotten me successfully up to
Chapter 7, but than it too is missing a bunch of words that are
in the book. I've been able to get most of Chapter 8, and 9 done
and now working on Chapter 10. Whew it's been a awesome
adventure! Forth is actually better than I initially thought and
I can't wait to see what I learn next about it. Once I've
finished both "Staring Forth" and "Thinking Forth" and gotten
some experience under my belt I'll be moving on to ARM Assembly.
Having those two under my belt is going to be blast!

Thank you for your time, patience and understanding. Any
assistance, ideas or suggestions would be greatly appreciated as
always. Take care now,

--
Darin Murphy


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

[Anton Ertl]

Darin Murphy <murphy...@gmail.com> writes:
> I've also tried gForth which has
> a crazy amount of words, and has gotten me successfully up to
> Chapter 7, but than it too is missing a bunch of words that are
> in the book.

I looked at the word summaries for Chapter 7 and following, and the
only word I found that's not in Gforth is OCTAL. If you find any more
words missing, please let me know.

: OCTAL 8 BASE ! ;

- 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/

[Darin Murphy]

an...@mips.complang.tuwien.ac.at (Anton Ertl) Wrote in message:

Anton,

Thanks for replying so quickly. Octal was the only word missing in
gforth in that chapter, but there were other issues with gforth
following chapter 7. The number examples: 12,345, 12/31/80 and
999-6784 both cause "Undefined Word" error in gForth. Only 12.
will create a double on the stack. The number example $200.00
creates the double 131072 0 on TOS. The only example that works
is 12. or 0. Also in the later chapters there are other
compatibilities and missing words too, but I don't have time
right now to pick through all of them.

The reason I am looking for a 100% compatible forth is because
"Starting Forth" has been used as the defacto Forth learning tool
for decades, but currently there isn't a forth I can find that is
compatible with it, which is strange considering it's current
incarnation is supposed to be 100% ANS Forth.

Take care now,

Darin Murphy

[rickman]

You may have come too close to calling out the troll. Beetlejuice,
Beetlejuice, Beetlejuice!

--

Rick C

[hughag...@gmail.com]

Darin Murphy is not a troll.

Rickman is a troll --- all of these idiotic posts of his have no purpose except that he hopes somebody will respond, then he will reply with more idiocy and divert the original topic into nonsense --- but now I have responded, so he is well on his way...

[hughag...@gmail.com]

On Saturday, April 1, 2017 at 9:10:44 AM UTC-7, Darin Murphy wrote:
> nearly finished with "Starting Forth". I like taking my time
> to make sure I understand things very well and have already made
> a much of small trivial programs outside of the book, including
> one that was a tiny rogue game using a only 1 dimensional array
> as the screen buffer. It was a blast!

"Starting Forth" is a classic, so everybody reads that --- it is not very good though --- I don't know of any Forth books that are any good.

I didn't know what structs were after reading "Starting Forth" --- I didn't learn about structs until I learned C, and then I brought the concept back with me to Forth --- there are no books from Forth Inc. that describe structs, most likely because Elizabeth Rather doesn't know what structs are.

I would avoid anything from Forth Inc.. You will pick up very bad habits, such as passing data between functions in global variables. You will be taught CREATE DOES> as the primary way to build data-structures, but this assumes that they will be built at compile-time --- most of the time you need to build them at run-time.

The best way to learn Forth is to write Forth programs --- you have already done that with your game --- if you post your code I will comment on it for you.

It is a mistake to rely too much on books. You end up being able to post code snippets from books, and claiming to be a big expert, but not being able to write programs of your own. Don't turn into this person:

On Sunday, August 9, 2015 at 7:30:10 PM UTC-7, Elizabeth D. Rather wrote:
> Here's [an array definer] presented in my Forth Application Techniques that I think is
> far more useful than the FSL version:
>
> : ARRAY ( n -- ) CREATE DUP , CELLS ALLOT
> DOES> ( n -- a) SWAP OVER @ OVER < OVER
> 1 < OR ABORT" Out of Range" CELLS + ;

[Elizabeth D. Rather]

Actually, Starting Forth hasn't represented mainstream Forth usage since
the early 90's. There are several other good tutorials around, including
my book Forth Application Techniques (Amazon) that represent more
contemporary usage (co-resident under an OS, disk files for source
instead of blocks, additional facilities, etc.).

Cheers,
Elizabeth

--
Elizabeth R. Conklin
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA 90045
USA

[hughag...@gmail.com]

> It is a mistake to rely too much on books. You end up being able to post code snippets from books, and claiming to be a big expert, but not being able to write programs of your own. Don't turn into this person:
>
> On Sunday, August 9, 2015 at 7:30:10 PM UTC-7, Elizabeth D. Rather wrote:
> > Here's [an array definer] presented in my Forth Application Techniques that I think is
> > far more useful than the FSL version:
> >
> > : ARRAY ( n -- ) CREATE DUP , CELLS ALLOT
> > DOES> ( n -- a) SWAP OVER @ OVER < OVER
> > 1 < OR ABORT" Out of Range" CELLS + ;

As a novice-level exercise for brave Darin --- write a better array definer than Elizabeth Rather is capable of writing --- explain why it is better.

[Darin Murphy]

rickman <gnu...@gmail.com> Wrote in message:

Sorry Rick C, for giving that impression. I was just a bit
confused because so many Forths that I've looked at do not have
much documentation other than referring to "Staring Forth". I've
really enjoyed reading it and following along it's exercises, but
the further I get through the chapters ( On Chapter 10 currently
) the more I stumble with things not matching up in gforth (
Currently the only Forth that works both on my tablet and on my
Raspberry Pi 3 , that I know of ) and it makes it a little
frustrating. I am also reading "Thinking Forth" which really
helps me understand how to build my own programs and lexicons.
Currently I'm up to the chapter on creating a program that takes
standard numbers and converts them to Roman Numericals. Yeah I'm
sure it's pretty trivial, but for me it's a good start at
understanding how to break down a problem into smaller easier
pieces and whether to use logic, data or formula to solve those
smaller pieces.

[Darin Murphy]

"Elizabeth D. Rather" <era...@forth.com> Wrote in message:

Thanks Mrs. Conklin for your suggestion. I'll take a look at
"Forth Application Techniques" as soon as I can get the money up!
If you know of any other tutorials, links to further
information, etc., please let me know. Take care
now.

[Darin Murphy]

hughag...@gmail.com Wrote in message:

Thanks for your suggestion Hugh. Currently I'm at "Chapter 10. I/O
and You". I just checked and Chapter 11 talks about both "CREATE"
and "DOES>", so I'll look into creating my version of an array
definer when I finish it. Whew it's an incredible journey
learning Forth, a lot more than any of the other languages I've
studied, and I know that Forth my First and most used language.
The second will be Assembly for the ARM processor. Once I've
learned enough Forth to be able to get myself in trouble, LOL!!!,
I'll be studying ARM Assembly. Those two will be a powerful combo
indeed. I did learn 8086 Assembly many years ago, so I understand
how binary, bit masking, LShifts/RShifting, Binary Logic, things
like that work, just need to understand how ARM Assembly does
them. Anyway, Thanks again Hugh for all of your guidance and
suggestions. Take care now,

[Paul Rubin]

Darin Murphy <murphy...@gmail.com> writes:
> Once I've learned enough Forth... I'll be studying ARM

> Assembly. Those two will be a powerful combo indeed. I did learn 8086

> Assembly many years ago...

If you've done Forth and an assembly language already, instead of
another assembler (it won't be that much different than the first) I'd
try out a higher level language as the next step of your journey.
Python is a popular choice these days, or Scheme if you want something
with more purity.

[lehs]

Make a list of words that lacks or deviate. Then extend/redefine to a system equivalent with the Forth in 'Starting Forth'.

[Jan Coombs]

On Sat, 1 Apr 2017 12:10:50 -0400 (EDT)
Darin Murphy <murphy...@gmail.com> wrote:
[...]

> Anyway, I've stumbled upon an issue with the book and was
> wondering if someone knew where I can find a free forth that
> works with my Raspberry Pi and uses all of the same exact
> words as the ones in "Starting Forth" on Forth Inc.'s site?

No, but have you seen this:

"In this transcript Forth code has been ANSified. The samples
should run on, at least, iForth and SwiftForth. Where necessary,
statements that were valid in 1981 have been exchanged with
statements more appropriate for 2003 (when this tribute was
written)."

from:
http://home.iae.nl/users/mhx/sf.html


Jan Coombs

[Darin Murphy]

Jan Coombs <jenfhaom...@murmic.plus.com> Wrote in message:

Jan, thank you for reminding me about this paragraph on Forth
Inc.'s site. Yes I was aware of it, that's why I was asking about
any "free" version of Forth, since iForth and SwiftForth are both
paid programs. Currently neither of them would work on my
Raspberry Pi or Google Pixel C tablet even if I had the money to
buy them. Again thank you for your assistance. Take care
now.

[Anton Ertl]

Darin Murphy <murphy...@gmail.com> writes:
> The number examples: 12,345, 12/31/80 and
> 999-6784 both cause "Undefined Word" error in gForth.

SwiftForth accepts these as numbers, but I don't think there's a
version for the Raspi.

> The number example $200.00
> creates the double 131072 0 on TOS.

It does so in SwiftForth, too, and actually in any Forth-2012
compliant Forth, because the $ prefix indicates a hex number. I think
that Starting Forth shows $200.00 only as output of a number
formatting word, not as input for text interpreter number conversion.

>The reason I am looking for a 100% compatible forth is because
> "Starting Forth" has been used as the defacto Forth learning tool
> for decades, but currently there isn't a forth I can find that is
> compatible with it, which is strange considering it's current
> incarnation is supposed to be 100% ANS Forth.

OCTAL has not been standardized in ANS Forth, nor have non-digit
characters in numbers, other than "." and a "-" prefix to indicate
negation; Forth-2012 added the prefixes # (decimal), $ (hex), %
(binary), and the '<char>' notation.

[Darin Murphy]

Paul Rubin <no.e...@nospam.invalid> Wrote in message:

Thank you Paul for the suggestion, but I have already studied
Python, Javascript and Scheme. Actually, I've studied many
different programming languages in my search over the last 37
years to find the, simplest, most extensible, easiest to
understand and efficient language . So far Assembly and Forth
are it. While Python is very easy to pick up, it is way to
inflexible, inextensible, and very, very slow. Javascript, while
dominating the internet, is extremely popular and far faster than
Python, is still very messy unless you keep to strick practices,
also outside of nodeJ is restricted to webpages. Scheme while a
"pure" functional language, far more flexible and extensible with
it's Macro, than either Javascript or Python it too has its
issues, like enforcing parenthesis everywhere, due to it's
"polish notation", making it really difficult to type/read, and
can be very bloated, very quickly. Finally none of the three you
mention can be easily built from assembly to a working OS,
Compiler/Interpreter, Assembler, that takes up little space, be
easy to pickup/use, and can be completely transformed into
whatever language is needed to solve the problem. I understand
every language has it's trade off, but the only issue with Forth
is it's lack of popularity and libraries, which isn't the fault
of the language itself. Forth can be whatever it needs to be
period. You can make it object-oriented, functional, even
Declarative if you put the time and effort in it. It can run on
just about any hardware that has more than a kilobyte or 2 of
memory. It is easy to learn and read, unless your trying to make
it as cryptic, compared to languages like C, C++, Objective C,
even though it's far more flexible, adaptable and extensible and
if built for it can also be just as fast, while taking up less
space. The only con I can see with Forth is due to it's lack of
popularity, which to me means nothing, lack of libraries, again
to me means nothing, turmoil in it's ranks of advocators, which
has nothing with the language. Now there is still a lot I have to
learn about Forth, but I will learn it because I've seen, walked
and played in the grass on the side for the last 37 and it's not
greener. Take care now.

[Ron Aaron]

On 02/04/2017 18:16, Darin Murphy wrote:

> Jan, thank you for reminding me about this paragraph on Forth
> Inc.'s site. Yes I was aware of it, that's why I was asking about
> any "free" version of Forth, since iForth and SwiftForth are both
> paid programs. Currently neither of them would work on my
> Raspberry Pi or Google Pixel C tablet even if I had the money to
> buy them. Again thank you for your assistance. Take care
> now.

Hello, Darin -

You may, perhaps, be interested in taking a look at 8th. It runs on RPi
as well as desktops and mobile systems. The free version has most of the
functionality of the non-free versions. However, it is not ANS Forth.

[rickman]

Really? Is that what the words, "starting Forth" mean to you?

If you were selling a teenager their first car would you offer a set of
wrenches in place of a warranty?

--

Rick C

[Darin Murphy]

Darin Murphy <murphy...@gmail.com> Wrote in message:

Oh! Sorry Paul, I forgot one of con of Forth and that's it lacks
updated Tutorials for complete beginners, other than "Starting
Forth", which is okay. "Starting Forth" worked flawlessly for me
up to Chapter 7, and only there had an issue with having numbers
like 12,345 ; 555-555-1212 ; and 10/31/80. It was useful enough
for me to understand the stack, how to manipulate it, how the
interpreter/compiler works, fixed point arithmetic, how to change
the base, how to build my own words from scratch, how loops work,
conditional branching, basically the basis of programming. Now
I'm learning deeper parts of Forth and loving it. Take care now.

[rickman]

> Sorry Rick C, for giving that impression.

No, my bad. I wasn't trying to say you were troll baiting. This was my
attempt at being funny. Seems no one got it.

I just have seen so much of what sets Hugh off that I know when people
inadvertently wave their red handkerchief Hugh will come charging out.

> I was just a bit
> confused because so many Forths that I've looked at do not have
> much documentation other than referring to "Staring Forth".

Yes, learning Forth from scratch can be a tough road. I'm like you in
that I prefer not to find the road by exploring rough terrain. I'd much
rather follow others footsteps. My goal in using Forth is not to
explore Forth, but to use it. I find interesting many of the issues
discussed in c.l.f but I don't often put them to practice.

> I've
> really enjoyed reading it and following along it's exercises, but
> the further I get through the chapters ( On Chapter 10 currently
> ) the more I stumble with things not matching up in gforth (
> Currently the only Forth that works both on my tablet and on my
> Raspberry Pi 3 , that I know of ) and it makes it a little
> frustrating.

Then I would say you have come to the right place. If you wish to give
back to the community, you can carefully document the problems you find
and perhaps someone will come up with changes either to "Starting Forth"
or a "Starting Forth" compatibility module for gForth.

I'm not a frequent user of gForth, but I also have Raspberry Pis and do
use it sometimes. In fact, I am currently working on a project using a
TI MSP430 launchpad board and will be connecting to that through a
Raspberry Pi. So gForth may feature prominently in that effort soon.

> I am also reading "Thinking Forth" which really
> helps me understand how to build my own programs and lexicons.
> Currently I'm up to the chapter on creating a program that takes
> standard numbers and converts them to Roman Numericals. Yeah I'm
> sure it's pretty trivial, but for me it's a good start at
> understanding how to break down a problem into smaller easier
> pieces and whether to use logic, data or formula to solve those
> smaller pieces.

Sure, that's great. What are you thinking of using Forth for when you
get out of the student stage?

--

Rick C

[rickman]

It has been a very long time since I read "Starting Forth". With the
help of folks in this group I created a small library of array creating
words that I use each time I write a significant program in Forth.
However, I am not so fluent in the language that I recall the details of
how these library words work. So each time I end up improving my
documentation, lol.

Hugh may seem at times as mad as a hatter, but he *is* very
knowledgeable in Forth. He has written a "novice" package which would
be good material for you to go through after you have finished your
books. You may not want to use every feature in his library, but from
what he says it seems like it shows many useful features and can show
you how real code is written, not just teaching examples. Just a thought.

I assume every other comment in his novice package isn't a slam against
Forth, Inc. Elizabeth Rather or the Forth technical committee.

--

Rick C

[Albert van der Horst]

In article <oboje2$pce$1...@gioia.aioe.org>,

Darin Murphy <murphy...@gmail.com> wrote:
>Hey everybody!
>
>It's been a very, very long time since I posted on this site. Was
> away from Forth for 6 months trying to go to UOPeople, which
> wasn't what I expected. I started back up with Forth in Dec 2016
> and nearly finished with "Starting Forth". I like taking my time
> to make sure I understand things very well and have already made
> a much of small trivial programs outside of the book, including
> one that was a tiny rogue game using a only 1 dimensional array
> as the screen buffer. It was a blast!

Starting Forth can still be used to learn Forth.

>
>Anyway, I've stumbled upon an issue with the book and was
> wondering if someone knew where I can find a free forth that
> works with my Raspberry Pi and uses all of the same exact words
> as the ones in "Starting Forth" on Forth Inc.'s site? I
> understand it's a tall order, but just thought I'd ask. I've
> already tried 4e4th, which is a great little Forth that runs on a
> MSP430, but it's so small that it's missing a lot of words (i.e.,
> missing all of Chapter 3 words). I've also tried gForth which has
> a crazy amount of words, and has gotten me successfully up to
> Chapter 7, but than it too is missing a bunch of words that are
> in the book. I've been able to get most of Chapter 8, and 9 done
> and now working on Chapter 10. Whew it's been a awesome
> adventure! Forth is actually better than I initially thought and
> I can't wait to see what I learn next about it. Once I've
> finished both "Staring Forth" and "Thinking Forth" and gotten
> some experience under my belt I'll be moving on to ARM Assembly.
> Having those two under my belt is going to be blast!

You should use a version of Starting Forth that has been modernized
if you're diligently doing all the exercises. The version of
Marcel Hendrix is great for that. The only disadvantage is the
artwork. I like the original pictures better.

>
>Thank you for your time, patience and understanding. Any
> assistance, ideas or suggestions would be greatly appreciated as
> always. Take care now,
>
>--
>Darin Murphy

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

[hughag...@gmail.com]

On Sunday, April 2, 2017 at 1:02:43 PM UTC-7, Albert van der Horst wrote:
> Starting Forth can still be used to learn Forth.

I strongly advise against using Forth Inc. books to learn Forth (with the exception of "Thinking Forth" although that is only useful after you have begun writing programs).

The "Starting Forth" book is a negative contribution --- you will pick up bad habits --- it will be very difficult for you to throw them off (it took me years).

I have said before that the distinction between novice-level Forth and intermediate-level Forth is that intermediate-level Forth involves writing your own data-structures. I don't recommend that you attempt this as a novice, because you are not ready. You are better off as a novice to use data-structures provided to you by intermediate-level Forth programmers while you get some experience writing programs. It is actually okay to stay at the novice-level for years and just write programs --- there is nothing wrong with writing programs!

Note that Andrew Haley is on the Forth-200x committee, and he is still novice-level. He is not capable of implementing data-structures, which I have described as intermediate-level Forth. He attempted this, but his code wasn't general-purpose because it didn't support arrays of structs --- only arrays of cells (they can be pointers to structs though) --- this isn't really general-purpose because you want to support arrays of floats, doubles, etc..

Here is my ARY array definer from the novice-package. I don't really expect you to understand how it works (it is intermediate-level, and it relies on other novice-package features that are also intermediate-level). You can learn to use it though --- it is useful for writing programs.
---------------------------------------------------------------------------

\ ******
\ ****** These are an alternate definition of arrays using Iliffe arrays (http://en.wikipedia.org/wiki/Iliffe_vector).
\ ****** This code was originally written by Andrew Haley using CREATE DOES> and was limited to word elements.
\ ****** I upgraded the code to allow for user-specified element sizes.
\ ******

: [] ( adr index - element-adr ) \ not a MACRO: because it might be used interactively
cells + ;

: -> ( adr index -- element ) \ not a MACRO: because it might be used interactively
[] @ ;

: ,rows ( size 0 dims... -- size 0 dims... ) \ size is the size of the element; all elements get zero'd out
here locals| array dim | \ ARRAY is the adr and DIM is the largest dimension
dup if w else over then \ -- element-size \ all but the last level are pointers (size W)
dim * allot
dup if
dim 0 do here array I [] ! dup >r recurse r> loop
then ;

\ Any alignment to the dictionary pointer should be done *before* ,ROWS is called.
\ This is in <ARY> prior to the DIMENSIONS.
\ This isn't necessary in ,ROWS prior to the RECURSE because we have only been compiling words.
\ Don't align the HERE at the beginning of ,ROWS as this has to be the same HERE that was obtained prior to calling ,ROWS.

: dimensions ( size 0 dims... size ) \ size is the size of the element
,rows
begin 0= until ; \ discard the dimensions and the zero terminator

: <ary> ( size 0 dims... name -- )
>r
non-zeros >r r@ 0 = abort" *** ARY needs some dimensions ***"
align here >r dimensions >r
r> r> r> r> { siz adr cnt name -- }
name get-current :name \ runtime: indices... -- element-adr
adr lit,
cnt 1 ?do swap, postpone -> loop
swap, siz lit*, +, ;,
c" <" name get-current :2name \ runtime: -- base-adr
adr lit, ;,
name c" >" get-current :2name \ runtime: adr index -- element-adr
siz lit*, +, ;,
;

: ary ( size 0 dims... -- )
bl word hstr dup >r <ary> r> dealloc ;

\ You can define a two-dimensional array of words in either of these ways:
\ W 0 3 5 C" TEST" <ARY>
\ W 0 3 5 ARY TEST

\ Assuming that I and J are indexes, an element can be accessed like this:
\ I J TEST \ this provides the element address, which you can @ or ! to.
\ In the above, I is in the range [0,3) and J is in the range [0,5). They are in the same order as the dimensions were.

\ It is also possible to access the element like this:
\ <TEST J -> I TEST> \ this provides the element address, which you can @ or ! to.
\ In the above, I is in the range [0,3) and J is in the range [0,5). They are in the opposite order as the dimensions were.

\ The [] only works for word-sized elements.
\ You should always use the xxx> word (even for words) because it takes into account the size of the element.

\ Arrays of dimensions other than two are defined the same --- you can have as many dimensions as you want.
\ <ARY> figures out how many dimensions there are by looking for the 0 under the non-zero dimensions.

\ This is a classic example of the problem with CREATE DOES> words being limited to *one* action per data type.
\ The CREATE DOES> version of the Iliff vectors relied on [] for resolving the final level, which had to be word elements.
\ There is no way to do this with CREATE DOES> because you can't have a type-specific version of [] (such as my xxx> word).

[Darin Murphy]

rickman <gnu...@gmail.com> Wrote in message:

> No, my bad. I wasn't trying to say you were troll baiting. This was my
> attempt at being funny. Seems no one got it.
>
> I just have seen so much of what sets Hugh off that I know when people
> inadvertently wave their red handkerchief Hugh will come charging out.

It's okay. Sometimes I can't tell when other people are joking
unless they literally put "j/k" at the end of a text, through at
the beginner would probably be better. LOL!!!

> Yes, learning Forth from scratch can be a tough road. I'm like you in
> that I prefer not to find the road by exploring rough terrain. I'd much
> rather follow others footsteps. My goal in using Forth is not to
> explore Forth, but to use it. I find interesting many of the issues
> discussed in c.l.f but I don't often put them to practice.

Actually Forth seems to be easier for me than say "C++" with it's
"Multiple inheritance" and at the time I was studying it "buggy
templates", and both "C and C++ " have header files which I hated
with a passion. Programming shouldn't be as complicated as C++
makes it. I think performing "brain surgery" with salad tongs,
wearing oven mittens would simpler than writing a large database
application in C++ even with it's millions of libraries. LOL!!!
It's languages like C, C++ that spurred scripting languages like
Python, Ruby and Javascript.

Yes the newsgroup is full of years and years of useful, learning
information. I sometimes just go backwards in time, reading about
the different issues and their solutions that the group have
posted. I tried to avoid all the noise from trolls and flame
wars that went on. Thank goodness it's mostly useful
information.

> I'm not a frequent user of gForth, but I also have Raspberry Pis and do
> use it sometimes. In fact, I am currently working on a project using a
> TI MSP430 launchpad board and will be connecting to that through a
> Raspberry Pi. So gForth may feature prominently in that effort soon.

gForth is currently my only real choice since it works both on my
Google Pixel C and my Raspberry Pi 3. It has hundreds of words,
and has a very comprehensive manual the manual can be a bit
cryptic at times, but overall it's been very helpful while I
follow along in "Starting Forth".

Dirk Bruehl from "Forth Programming Language" forum on Facebook
was kind enough to send me a TI MSP430 Launchpad that comes with
a tiny little MSP430G2553 preloaded with 4e4th on it! I'm able to
communicate with it via minicon on my RPi 3. It's fun playing
with that little guy and reminds me of the days when I had a 8088
though the later felt a lot bigger. LOL!!!

The Raspberry Pi 3 is an awesome little machine. Also recently
Broadcom has opened it's graphic chip, so to speak, so bare metal
programming on it has become more accessible. There's even a
working baremetal Forth OS based upon JonesForth called
piJFORTHos:

https://github.com/organix/pijFORTHos

Which I'll be digging into once I can get myself another Raspberry
Pi 3, which should be by the time I finish studying "Staring
Forth", hopefully! LOL!!!

> Sure, that's great. What are you thinking of using Forth for when you
> get out of the student stage?

Once I feel confident enough in Forth, I'm going to be brushing up
on Assembly with ARM Asseembly. I studied and wrote 8086 assembly
many years ago, but stoppend when I started looking for a good
language to compliment it. C at the time was really the only
language that I could find which allowed inlining with Assembly.
Now that I have found Forth, I'm back in business! Well I'm going
to be getting another RPi 3, and using PijFORTHos to continue my
studies by adding an Assembler to it, so I can build Forth
drivers to access the rest of the Raspberry Pi's hardware. It's
going to be hard, but also it's going to be a blast!!!
LOL!!!

Take care now,

[rickman]

If you like the launchpad, you might want to take a look at Mecrisp.
I've used it on a TI ARM launchpad and now am working on an MSP430FR4133
launchpad because it has an LCD display. I found the MSP430 unit easier
to get up and running because TI provides drivers that work easily. To
get the ARM launchpad up and running required installation (Windows 8)
an unsigned driver which is a project in itself. I ended up using the
rPi just because it would flash the board. Then I remoted to the pair
from the PC. I don't remember any of the details though. So far the
MSP430 launchpad has been used directly from the laptop, but if I can
get a remote reboot to work through a USB hub, I might remote that via
the rPi as well.

--

Rick C

[Darin Murphy]

Rick thanks for replying, but I only own a Raspberry Pi 3 and a
Google Pixel C (tablet), so no Windows anything. I connect to my
Launchpad, which was loaded with 4e4th by Dirk for me, via my
Raspberry Pi 3 using minicon. That launchpad is a great example
of how tiny Forth can exist, and while it's a good test machine (
can't accidently destroy my Forth while programming it ), I'm
looking forward to running pijForthos on another Raspberry Pi 3,
which I plan on getting in a couple of months, once I finish
"Starting Forth". pijForthos doesn't have video, or any real
network drivers, but does allow communication and file uploads
via usb-to-serial, so I'll be connecting one Raspberry Pi 3 from
another using minicon like I connect to my launchpad. It's going
to a an awesome experience living in a Forth world with the power
of a Raspberry Pi 3. LOL!!!

[Darin Murphy]

Actually I think pijForth was built for a Raspberry Pi 2b or 2b+,
but not 100% so I'm going to have to do some research. Even if it
was a Pi Zero, I'd still buy it just to have Forth in it's own
little world, besides a Pi Zero will still be amazing considering
how tiny a ForthOS is. LOL!!!

[hughag...@gmail.com]

On Saturday, April 1, 2017 at 9:10:44 AM UTC-7, Darin Murphy wrote:

> I ... have already made
> ... small trivial programs outside of the book, including

> one that was a tiny rogue game using a only 1 dimensional array
> as the screen buffer. It was a blast!

Show us the code!

Endlessly talking about Forth without posting any code is typical of the ANS-Forth cult members --- don't be one of them!

I post ANS-Forth code all the time. Of course, Elizabeth Rather and Stephen Pelc insist that I'm not an ANS-Forth programmer and never will be. Perhaps that is why you aren't posting code? You expect Elizabeth Rather and Stephen Pelc will say the same about you? You hope that, by never posting any ANS-Forth code, you can stay in their good graces and eventually be recognized by them as a big ANS-Forth expert?

[Darin Murphy]

\ Okay Hugh here it is!

\ tiny_arena01.fs
\ Created by Darin Murphy
\ Created on 02/24/17

\ Currently the walls of the arena are finished and the player may
move about the area using the arrow keys
\ Loads and runs fine from my Raspberry Pi 3 B running gforth
\ To load up if in linux type: gforth tiny-arena01.fs, then after
gforth loads type: player-walking.
\ Eventually it will have monsters spinkled over the arena and
everytime the player fights one by ramming
\ into it they will get a score and can die if the monster hurts
them too much. Fights will be determined
\ randomly. Had to stop working on it, until I can find a small
and fast randomizer formula.

64 constant plyrsymbl \ "@" symbol of player
35 constant wallsymbl \ "#" symbol of wall
77 constant mnstrsymbl \ "M" symbol of monster
32 constant mptyspace \ " " empty space

\ screen array which represents the console screen 80 x 25
characters or 2000 cells
variable scrnarry 1999 cells allot

\ fill screen array with empty space " "
: clear-screen ( -- ) 1999 0 do mptyspace scrnarry i cells + ! loop ;

\ current positon of a mobile unit ( monster/player )
variable curpos
0 curpos ! \ initialize it to 0 for safty

\ previous position of a mobile unit ( monster/player )
variable prevpos
0 prevpos ! \ initialize it to 0 for safty

\ player's position
variable plyrpos
10 80 * 40 + plyrpos ! \ starting position

\ monster's position
variable mnsterpos

\ used for building room
variable counter
0 counter !

\ health points of player
variable health
10 health !

\ player's score for killing monsters
variable score
0 score !

\ screen array helper words
: clear-prevpos ( position -- ) mptyspace scrnarry prevpos @ cells
+ ! ;
: y1- ( -- n ) curpos @ 80 - ;
: y1+ ( -- n ) curpos @ 80 + ;
: x1- ( -- n ) curpos @ 1 - ;
: x1+ ( -- n ) curpos @ 1 + ;

\ copies current position to previous postion
: curpos>prevpos ( -- ) curpos @ prevpos ! ;

\ scans current position in screen array to determine whether
mobile unit there is player
\ or monster
: get-moversymbl ( -- identity ) scrnarry curpos @ cells + @ ;

\ checking position in screen array
: look-forward ( -- n ) y1- cells scrnarry + @ ;
: look-behind ( -- n ) y1+ cells scrnarry + @ ;
: look-left ( -- n ) x1- cells scrnarry + @ ;
: look-right ( -- n ) x1+ cells scrnarry + @ ;

\ identifying if there is something/someone at a particular
position and if so,
\ who/what are they
: clear? ( new position -- boolean flag ) mptyspace = ;
: wall? ( new position -- boolean flag ) wallsymbl = ;
: monster? ( new position -- boolean flag ) mnstrsymbl = ;
: player? ( new position -- boolean flag ) plyrsymbl = ;

\ goto postion in screen array
: goto-position ( symbol -- ) scrnarry curpos @ cells + ! ;

\ moving forward, backward, left, or right entails copying current
postion to previous position
\ updating curpos, updating screen array with new location, and
\ finally removing previous position in screen array
: move-forward ( -- ) get-moversymbl curpos>prevpos y1- curpos !
goto-position clear-prevpos ;

: move-backward ( -- ) get-moversymbl curpos>prevpos y1+ curpos
! goto-position clear-prevpos ;

: move-left ( -- ) get-moversymbl curpos>prevpos x1- curpos !
goto-position clear-prevpos ;

: move-right ( -- ) get-moversymbl curpos>prevpos x1+ curpos !
goto-position clear-prevpos ;

\ before moving to new position, first determine if position is
clear, if so move there
: go-forward ( -- n ) look-forward dup clear? if drop
move-forward else drop
then ;

: go-backward ( -- n ) look-behind dup clear? if drop
move-backward else drop
then ;

: go-left ( -- n ) look-left dup clear? if drop move-left else drop
then ;

: go-right ( -- n ) look-right dup clear? if drop move-right else drop
then ;

\ initializing screen array before starting program
clear-screen

\ update screen from screen array
: update-screen ( -- ) page 1999 0 do scrnarry i cells + @ emit loop ;

\ Building a large room (takes up the whole screen) by encircling
it with walls of #
: north-wall ( -- ) 79 0 do wallsymbl scrnarry i cells + ! loop ;

: estwst-walls ( -- ) 21 0 do counter @ 79 + counter ! wallsymbl
scrnarry counter @ cells + !
counter @ 1 + counter ! wallsymbl
scrnarry counter @ cells + !
loop 0 counter ! ;

: south-wall ( -- ) 21 80 * counter @ + counter ! 80 0 do
wallsymbl scrnarry counter @ i + cells + !
loop 0
counter ! ;
: build-arena ( -- ) north-wall estwst-walls south-wall ;

\ build arena, then add player to screen array at starting postion
build-arena
plyrpos @ curpos !
plyrsymbl scrnarry curpos @ cells + !

\ Main loop, which takes player's key input every turn, moves
player accordingly, refreshes screen too
\ if player presses the q key then the player wants to quit so the
loop exits
: player-walking ( -- ) begin update-screen ekey dup 113 = if
drop page exit
else
dup k-up = if drop go-forward
else
dup k-down = if drop go-backward
else
dup k-left = if drop go-left
else
dup k-right = if drop go-right
else drop
then
then then then then
again ;

\ Let me know if I need to document further or if I am able to
factor things better. Take care now.

[Julian Fondren]

On Sunday, April 2, 2017 at 9:46:37 PM UTC-5, Darin Murphy wrote:
> \ Eventually it will have monsters spinkled over the arena and
> everytime the player fights one by ramming
> \ into it they will get a score and can die if the monster hurts
> them too much. Fights will be determined
> \ randomly. Had to stop working on it, until I can find a small
> and fast randomizer formula.

gforth comes with one in random.fs

Probably these are enough:
https://en.wikipedia.org/wiki/Linear_congruential_generator

>
> 64 constant plyrsymbl \ "@" symbol of player
> 35 constant wallsymbl \ "#" symbol of wall
> 77 constant mnstrsymbl \ "M" symbol of monster
> 32 constant mptyspace \ " " empty space
>

I suggest treating "#@ M#" as an internal data structure and not
worrying about whether you'll want to change them later. You have can
your page-drawing routing translate them to something else, at that
point.

I also suggest using CHAR and [CHAR] and BL instead of these literal
numbers.

It's weird how you have these constants and then have 80, 1999, 25,
and such throughout your code.



Of your names...

mptyspace
plyrsymbl
mnsterpos
scrnarry

I worry that if I use gentle tone that you'll conclude that they're
not so bad, so let's just say that you deserve the death penalty for
these names. I won't hear any libertarian talk about how you're
practicing your naming in the privacy of your own home and aren't
harming anyone. You will be made an example of.

> \ Let me know if I need to document further or if I am able to
> factor things better. Take care now.

You document overall usage and every individual word. That
documentation is OK enough--but do you see that it's incomplete? One
still needs to read your entire program to get a sense of how it
actually works. That can be documented also.

In general it's alright, and you can make a playable game from this.
I've posted similar code, and sokoban.fs (included with gforth), is in
this class of programs. sokoban.fs has an exhaustive (if the bug's
fixed--the original code missed a case) pattern-matching movement
system that works well with the small number of symbols involved.

[Ron Aaron]

On 03/04/2017 6:38, Julian Fondren wrote:
...

> Of your names...
>
> mptyspace
> plyrsymbl
> mnsterpos
> scrnarry
>
> I worry that if I use gentle tone that you'll conclude that they're
> not so bad, so let's just say that you deserve the death penalty for
> these names. I won't hear any libertarian talk about how you're
> practicing your naming in the privacy of your own home and aren't
> harming anyone. You will be made an example of.

Julian: Darren already mentioned he has trouble discerning humor from
serious discussion...

Darren: your variable names are much better than "x", "x1", "x2" etc.
that people often use. That said, you should give thought to
readability for your future use.

"empty_space" is better than "mptyspace", for instance.

[Darin Murphy]

Julian Fondren <julian....@gmail.com> Wrote in message:

Thank you Julian for your honesty and suggestions. Would you give
me some examples of the names you would suggest being more
acceptable? My experiences have been with C-like abrievations,
which are even more cryptic then mine, so I am still learning
about how Forther's create them. The reason I used the numbers
mentioned instead of variables or constants was because the
program is small enough I didn't need to worry about keeping
track of them. if those numbers were going to be used more often
or being changed for different console resolutions (45x100,
65x120, etc.,), then I would have created variables to hold them
near the top of the program so that other programmers would have
found them easy enough to change if needed. Your right about the
code needs to be self documenting, and I will work on improving
it's readability in the future, but just unlearning old C-like
habits and learning more literate programming ones. Take care
now,
--
Darin Murphy

[Darin Murphy]

Ron Aaron <ramb...@gmail.com> Wrote in message:

Thanks Ron, and you and Julian are right. I usually do use longer
more clearer names, but have always been told I'm too verbose, so
I've been trying to shrink things down. He, he, he. Well looks
like I'm damned if I do, damned if I don't. LOL!!! Take care
now.
--
Darin Murphy

[Ron Aaron]

On 04/03/17 07:17, Darin Murphy wrote:

> Thanks Ron, and you and Julian are right. I usually do use longer
> more clearer names, but have always been told I'm too verbose, so
> I've been trying to shrink things down.

I can only say that when I return to code after a few months, it can
take longer to understand it than it did to originally write it, if I
didn't use a self-documenting code style.

So since the compiler doesn't care how long the identifiers are, and if
you use a good text-editor it likewise won't make a difference, you
should always prefer more descriptive identifiers (both for
function/word names as well as variables).

[Julian Fondren]

On Sunday, April 2, 2017 at 11:15:41 PM UTC-5, Darin Murphy wrote:
> Thank you Julian for your honesty and suggestions. Would you give
> me some examples of the names you would suggest being more
> acceptable? My experiences have been with C-like abrievations,
> which are even more cryptic then mine, so I am still learning
> about how Forther's create them.

The Forth ideal is a short English word: GET PUT PLACE DUMP TYPE
No symbols, no dashes, not many syllables, and it's a real word from
natural language. Forth's dictionary uniquely helps to support names
like this, because you can define and use a short appropriate name
even if it's already come up in earlier code.

If you can't help it, names-like-this will do. They are at least
clear. Wil Baden used a lot of Names-Like-This

Forth has a number of mnemonic characters that you can use to shorten
the length of words:

>STACK push something to a stack
LOCATION@ fetch something from a location
SETTING! update the value of a setting
.ARENA print the arena
0ARENA zero the arena -- so, initialize or reset it

A pitfall open to all programmers in all languages is abbreviated
names like yours. Aesthetics aside, it's hard to remember how the name
was abbreviated (is it plyrsymbl or plyrssymbl , second s from 's?),
and it can be hard to tell what the abbreviated name means (note your
various comments that just expand the name of the variable). You may
be comfortable with abbreviation until you come across someone else
who follows this practice, who abbreviates differently from you.

A pitfall open to Forth, somewhat encouraged by the mnemonics (anyway,
that's how I fell into it), is going too far with symbols. I had words
that consisted of nothing but symbols that basically encoded what the
word did in its name. That was a dark period in my life.

You can also use mnemonics within a program, like

\ prefix ' <-- symbol. 'WORD is the symbol for that word
char @ constant 'player
char # constant 'wall
char M constant 'monster
bl constant 'empty

\ prefix @ <-- location. @WORD is the location of that word
variable @player
variable @monster
variable @current
variable @last

\ postfix [] <-- array, like in C :/
create screen[] 2000 cells allot

You can also use wordlists and have a word that selects the nature of
the next word, but that seems a little excessive...


Aim for the ideal. Settle with acceptable forms. Avoid pitfalls.

> The reason I used the numbers
> mentioned instead of variables or constants was because the
> program is small enough I didn't need to worry about keeping
> track of them. if those numbers were going to be used more often
> or being changed for different console resolutions (45x100,
> 65x120, etc.,), then I would have created variables to hold them
> near the top of the program so that other programmers would have
> found them easy enough to change if needed.

OK, I thought it might be something like that. I was more confused by
the presence of the constants you had than by the lack of other
constants for the other literals.

Of literals for ASCII characters, I just wondered if you were aware
that CHAR and [CHAR] are available.

[Paul Rubin]

Darin Murphy <murphy...@gmail.com> writes:
> Even if it was a Pi Zero, I'd still buy it just to have Forth in it's

> own little world...

Unfortunately they don't sell the Pi Zero any more, and it was never in
good supply. You might be able to find one on ebay or something.
They've replaced it with the Pi Zero W which has wifi, but I'm not sure
at all that the other low-level interfaces are completely the same.

Btw, when responding to other people's posts, it's great to supply
context by including the part that you're responding to. But it's best
to chop down the quote to exactly the part that's needed (like I did
above with your post), rather than including their entire post.

[Julian Fondren]

On Sunday, April 2, 2017 at 11:46:30 PM UTC-5, Paul Rubin wrote:
> Darin Murphy <murphy...@gmail.com> writes:
> > Even if it was a Pi Zero, I'd still buy it just to have Forth in it's
> > own little world...
>
> Unfortunately they don't sell the Pi Zero any more, and it was never in
> good supply. You might be able to find one on ebay or something.
> They've replaced it with the Pi Zero W which has wifi, but I'm not sure
> at all that the other low-level interfaces are completely the same.
>

https://getchip.com/ is pretty fun, and the chip itself is cheap.

The handheld's keyboard isn't pleasant.

[Paul Rubin]

Julian Fondren <julian....@gmail.com> writes:
> https://getchip.com/ is pretty fun, and the chip itself is cheap.
> The handheld's keyboard isn't pleasant.

Wow, they've got some nice stuff there, some of which I didn't know
about before. Almost Everything in the store is "Currently on
back-order. Estimated Shipping Q1 2017." though, and we're already in Q2 :/.

It's hard to tell the difference between the CHIP and CHIP PRO but
that's ok ;-).

From a Forth perspective these are Raspberry-Pi level computers, large
enough that Forth's traditional space-saving techniques don't bring much
benefit. I'd probably program them in HLL's unless there were good
reasons to do otherwise.

Might be a nice 8th platform, if Ron is listening ;-).

This board seems to call louder for Forth:
https://www.aliexpress.com/item//32369020878.html

[Ron Aaron]

On 04/03/17 08:26, Paul Rubin wrote:

> From a Forth perspective these are Raspberry-Pi level computers, large
> enough that Forth's traditional space-saving techniques don't bring much
> benefit. I'd probably program them in HLL's unless there were good
> reasons to do otherwise.
>
> Might be a nice 8th platform, if Ron is listening ;-).

Ron is always listening :)

From a cursory glance I'd guess the RPI 8th binary might "just work".
If not, and if there were demand for it, I'd be happy to make a port.
It's just a matter of time and money...

[Darin Murphy]

hughag...@gmail.com Wrote in message:

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

Here is my ARY array definer from the novice-package. I don't really expect you to understand how it works (it is intermediate-level, and it relies on other novice-package features that are also intermediate-level). You can learn to use it though --- it is useful for writing programs.
---------------------------------------------------------------------------

Thank you Hugh for another great example. So what would an "array definer" be used for? Is it a helper to make arrays easier to implement or use? I downloaded your novice package/library and will be going over it after I finish "Starting Forth", which won't be much longer. Only a couple of chapters to go! Again Hugh thank you for taking the time to show how an experienced Forth programmer does it. Take care now,

------------------------------------------------------------------------------
Darin Murphy

[Darin Murphy]

hughag...@gmail.com Wrote in message:

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

Here is my ARY array definer from the novice-package. I don't really expect you to understand how it works (it is intermediate-level, and it relies on other novice-package features that are also intermediate-level). You can learn to use it though --- it is useful for writing programs.
---------------------------------------------------------------------------

[Elizabeth D. Rather]

"Forth Application Techniques" is aimed at complete beginners in Forth,
but assumes basic computer knowledge (meaning of "cell", "byte", "memory
address", etc.). It is much more consistent with current Forths (Forth94
and later).

Cheers,
Elizabeth

--
Elizabeth R. Conklin
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA 90045
USA

[Elizabeth D. Rather]

From what I've seen of it, it seems to be attempting to generalize
imaginary application requirements, none of which have been relevant in
any of the applications I've worked on in the last 40 years.

[Elizabeth D. Rather]

On 4/2/17 5:16 AM, Darin Murphy wrote:
> Jan Coombs <jenfhaom...@murmic.plus.com> Wrote in message:
>> On Sat, 1 Apr 2017 12:10:50 -0400 (EDT)
>> Darin Murphy <murphy...@gmail.com> wrote:
>> [...]

>>> Anyway, I've stumbled upon an issue with the book and was
>>> wondering if someone knew where I can find a free forth that
>>> works with my Raspberry Pi and uses all of the same exact
>>> words as the ones in "Starting Forth" on Forth Inc.'s site?
>>

>> No, but have you seen this:
>>
>> "In this transcript Forth code has been ANSified. The samples
>> should run on, at least, iForth and SwiftForth. Where necessary,
>> statements that were valid in 1981 have been exchanged with
>> statements more appropriate for 2003 (when this tribute was
>> written)."
>>
>> from:
>> http://home.iae.nl/users/mhx/sf.html
>>
>>
>> Jan Coombs
>>
>>
>
> Jan, thank you for reminding me about this paragraph on Forth
> Inc.'s site. Yes I was aware of it, that's why I was asking about
> any "free" version of Forth, since iForth and SwiftForth are both
> paid programs. Currently neither of them would work on my
> Raspberry Pi or Google Pixel C tablet even if I had the money to
> buy them. Again thank you for your assistance. Take care
> now.

The evaluation versions of Swiftforth are free, and perfectly adequate
to your learning process. They also incorporate a lot of additional
documentation that you will find helpful. SwiftForth does run on a PC or
Mac. SwiftX is a cross-compiler that can produce code for a board such
as the Pi. It also has free evaluation versions suitable for learning
(limited only in the size of a target program that can be released).

[Anton Ertl]

alb...@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>You should use a version of Starting Forth that has been modernized
>if you're diligently doing all the exercises. The version of
>Marcel Hendrix is great for that.

For the issues he mentioned, Marcel Hendrix' version is the same as
the Forth, Inc. online version. I guess that the online version was
derived from Marcel Hendrix' version.

[rickman]

There are no standard arrays in Forth unless you count strings. Many
people have created their own array defining words. With advice from a
number of people here I created my own some time ago. Hugh has created
his in the novice package.

It has been discussed here a number of times and it seems there are two
main reasons why arrays have not been standardized. The first is
because arrays will vary a great deal and so standardization would
require a lot of words. The other is because arrays can be very easy to
implement. It's just addresses arithmetic unless you want to get fancy.
Defining array defining words is only at all difficult because it
requires understanding Forth at a little deeper level to know how to
define defining words. That's why Hugh says it is intermediate level
Forth. Otherwise arrays are pretty durn simple.

--

Rick C

[Darin Murphy]

Wow! Everytime I come here and I post a question it just blows my mind how many of you reply back with helpful answers, suggestions, advice, even with code examples. You all are just amazing! Thank you for taking the time out of your busy schedules, jobs, to help me become the best Forth programmer I can be. I really mean that! I am sure that if it wasn't for Anton, Rickman, Paul, Hugh and Mrs. Conklin, I'd still be tripping over how a "If Else Then" works. I know my code is pretty basic and newbie, but with all of your help and support, during my journey, I'll truly be a Forth programmer.

Take care now,

Darin Murphy

[hughag...@gmail.com]

On Monday, April 3, 2017 at 1:06:30 AM UTC-7, Elizabeth D. Rather wrote:
> On 4/2/17 6:58 AM, rickman wrote:
> > On 4/2/2017 1:39 AM, Darin Murphy wrote:
> >> hughag...@gmail.com Wrote in message:
> >>>> It is a mistake to rely too much on books. You end up being able to
> >>>> post code snippets from books, and claiming to be a big expert, but
> >>>> not being able to write programs of your own. Don't turn into this
> >>>> person:
> >>>>
> >>>> On Sunday, August 9, 2015 at 7:30:10 PM UTC-7, Elizabeth D. Rather
> >>>> wrote:
> >>>>> Here's [an array definer] presented in my Forth Application
> >>>>> Techniques that I think is
> >>>>> far more useful than the FSL version:
> >>>>>
> >>>>> : ARRAY ( n -- ) CREATE DUP , CELLS ALLOT
> >>>>> DOES> ( n -- a) SWAP OVER @ OVER < OVER
> >>>>> 1 < OR ABORT" Out of Range" CELLS + ;
> >>>
> >>> As a novice-level exercise for brave Darin --- write a better array
> >>> definer than Elizabeth Rather is capable of writing --- explain why
> >>> it is better.
> >>

> >> Thanks for your suggestion Hugh. ...

> > Hugh may seem at times as mad as a hatter, but he *is* very
> > knowledgeable in Forth. He has written a "novice" package which would
> > be good material for you to go through after you have finished your
> > books. You may not want to use every feature in his library, but from
> > what he says it seems like it shows many useful features and can show
> > you how real code is written, not just teaching examples. Just a thought.

I can never tell whether Rickman's comments are supposed to be sarcastic or humorous --- and I don't care --- I just wish that he would go away.

> From what I've seen of it, it seems to be attempting to generalize
> imaginary application requirements, none of which have been relevant in
> any of the applications I've worked on in the last 40 years.

The novice package is all about general-purpose data-structures. All programs need this, and have for 30 years. Going back 40 years (to the 1970s) however, this wasn't done very much (it was only done on mini-computers such as the DEC PDP-11 that had 64KB or even 128KB but cost tens of thousands of dollars). Elizabeth Rather's background in programming is COBOL that didn't support code libraries. Also, in the 1970s personal computers hadn't been invented yet, but micro-controllers of the day had such a small amount of memory and lack of addressing modes that they couldn't support code-libraries.

It seems to be news to you, but the world has changed since the 1970s --- Charles Moore's design decisions prior to getting kicked out of Forth Inc. in 1982 ceased to be relevant in the late 1980s (the Commodore-64 had 64KB of RAM and could support pretty big and complicated programs) --- ANS-Forth that came out in 1994 was basically 1970s technology; it was a weird anachronism with no practical value.

Also, it seems to be news to you that the array isn't the only data-structure available. You said:
-----------------------------------------------------------------------
Virtually every Forth application needs some kind of array structures. The
reason that some general-purpose one might be "little used" is because it's
so easy to make a version that does *exactly* what the application needs
rather than some generic definition. ... The objective is to master the
toolset and be able to think clearly about exactly what kind of arrays will
be useful in your application and then build exactly that kind.
-----------------------------------------------------------------------

Arrays are only useful in certain programs. They are almost always built at compile-time. Darin's game is an example; his array represents the screen. My LowDraw.4th program is another example (actually the only novice-package example of using an array); my array held all the probabilities for all the possible poker hands. It is not a coincidence that LowDraw.4th was my first-ever ANS-Forth program --- this is pretty novice-level programming --- I was starting out with something easy.

Most programs build a data-structure at run-time. It is not known at compile-time how big the data-structure will be. My LIST.4TH and ASSOCIATION.4TH are for this purpose. It is possible that arrays could be built at run-time (I have LIST>ARRAY that creates an array of pointers to nodes in the list) --- this might be useful if the data is to be sorted by multiple keys (one array for each key) --- if the data is to be sorted by only one key though, then ASSOCIATION.4TH would be a better choice (it provides ordered access; it is an LLRB tree internally).

Programming is all about data! People need data-structures! This has been true for 30+ years, and will continue to be true forever.

You and your sycophants can tell me every day that I'm utterly incompetent as a Forth programmer --- you are just making yourself look foolish --- my public-domain novice-package is certainly intermediate-level Forth, and my work experience in Forth is arguably advanced-level.

This is you making a slight upgrade to a code snippet from the "Starting Forth" book, and screwing it up:

On Sunday, August 9, 2015 at 7:30:10 PM UTC-7, Elizabeth D. Rather wrote:
> Here's [an array definer] presented in my Forth Application Techniques that I think is
> far more useful than the FSL version:
>
> : ARRAY ( n -- ) CREATE DUP , CELLS ALLOT
> DOES> ( n -- a) SWAP OVER @ OVER < OVER
> 1 < OR ABORT" Out of Range" CELLS + ;

You really aren't any good at Forth programming!

[Elizabeth D. Rather]

For 40 years I taught beginning Forth (the latest version of the course
notes are the basis of my book, Forth Application Techniques), and we
discussed defining words and multiple ways of defining arrays on the 3rd
day of a 5-day course. In a couple of hours, students know how to define
2-dimensional arrays with error checking. But more importantly, they
know how to design custom data objects with application-specific properties.

[hughag...@gmail.com]

On Monday, April 3, 2017 at 6:56:29 PM UTC-7, Elizabeth D. Rather wrote:
> On 4/3/17 4:23 AM, rickman wrote:
> > On 4/3/2017 2:49 AM, Darin Murphy wrote:
> >> hughag...@gmail.com Wrote in message:
> >>

> >> Here is my ARY array definer from the novice-package. I don't really
> >> expect you to understand how it works (it is intermediate-level, and
> >> it relies on other novice-package features that are also
> >> intermediate-level). You can learn to use it though --- it is useful
> >> for writing programs.

> For 40 years I taught beginning Forth (the latest version of the course
> notes are the basis of my book, Forth Application Techniques), and we
> discussed defining words and multiple ways of defining arrays on the 3rd
> day of a 5-day course. In a couple of hours, students know how to define
> 2-dimensional arrays with error checking. But more importantly, they
> know how to design custom data objects with application-specific properties.

For 40 years you made the Forth community look stupid with your ridiculous class and ridiculous book. You are similar to Julien Fondren --- you want to promote yourself from sub-novice to "leading expert" teacher --- you have never written any Forth programs, and you know almost nothing about the subject.

This is you:

On Sunday, August 9, 2015 at 7:30:10 PM UTC-7, Elizabeth D. Rather wrote:
> Here's [an array definer] presented in my Forth Application Techniques that I think is
> far more useful than the FSL version:
>
> : ARRAY ( n -- ) CREATE DUP , CELLS ALLOT
> DOES> ( n -- a) SWAP OVER @ OVER < OVER
> 1 < OR ABORT" Out of Range" CELLS + ;

This is Julien Fondren:

On Wednesday, March 8, 2017 at 8:59:39 PM UTC-7, Julian Fondren wrote:
> I suggest that the solution is this: write documentation AS IF it were
> written for a language with actually no list processing capabilities
> of note at all. Build those list processing capabilities using more
> primitive operations, perhaps wearily, as this were a chore the
> language required of you before you can get around to actually doing
> anything, but explaining the construction and its merits as you go.
> Then, at the end, say -- just kidding! This is all built in!
>
> Of course you can make it clear at the beginning that this is a
> pretense. Forth and lists are such a pair in the culture that a reader
> might otherwise discard your tutorial as some kind of weak troll.
>
> Here is where I'd like to submit my own example of a tutorial like
> this, but I've tried and it's actually very difficult to write Forth
> without lists. I hope that some of you who are in the middle of
> writing your next "what are monads?" mini-tutorial can give my
> suggestion a try, instead.
>
> But consider, with traditional link-first lists and these words...
>
> : each[ ( list -- )
> POSTPONE begin POSTPONE dup POSTPONE while ; immediate
>
> ( list -- list )
>
> : ]each ( list -- )
> POSTPONE @ POSTPONE repeat POSTPONE drop ; immediate

Notice the similarity? Both of you want to be teachers. Both of you are ignorant of how to implement singly-linked lists, although this is a very easy subject.

When you call yourself the "leading expert" on Forth, you hurt the Forth community by making us look stupid. When you surround yourself with sycophants such as Julien Fondren who are just as stupid as you are, but loyal as dogs, you hurt the Forth community by making us look like a cult. Your contribution to Forth for 40 years has been purely negative --- you, personally, are the reason why Forth lost popularity --- its because you are informed by ignorance and driven by arrogance.

[rickman]

I was being sincere which I am sure bothers you as much as if I were
being sardonic.

Oddly enough, I don't actually wish you would go away. I only wish you
could be a bit more normal and not express your obsessions about every
little slight being a conspiracy and your compulsions to constantly
attack a few (or is it most) people here. There is no doubt in my mind
that you are insane, but that isn't really saying a lot in this group. lol

--

Rick C

[JUERGEN]

Darin, thanks for posting, threw it at VFX, and it seems there are some words undefined - or are they pre-defined in gforth?

k-up, k-down, k-left, k-right

: player-walking ( -- ) begin update-screen ekey dup 113 = if
drop page exit
else
dup k-up = if drop go-forward
else
dup k-down = if drop go-backward
else
dup k-left = if drop go-left
else
dup k-right = if drop go-right
else drop
then
then then then then
again ;

This would be an ideal example for the VFXTESTAPP project, visual, just using a small 16 x 16 ASCII field there, and people could try it without installation, just download the VFXtestapp.exe and run your code in 16 x 16 for starters and your original 80 x 25 version https://wiki.forth-ev.de/doku.php/en:projects:a-start-with-forth:start

[Mark Wills]

Juergen

If you want something to port, port this:

http://turboforth.net/fun/darkstar.html

:-)

[JUERGEN]

Thanks Mark, had a quick look; this is still beyond my level. EasyForth SNAKE and Darin's game is about right. There are many Forth Levels - I guess I am still at level 2 ...

[joel...@gmail.com]

On Sunday, April 2, 2017 at 1:10:44 AM UTC+9, Darin Murphy wrote:
> Hey everybody!

>
> [...]
>
> Anyway, I've stumbled upon an issue with the book and was
> wondering if someone knew where I can find a free forth that
> works with my Raspberry Pi and uses all of the same exact words
> as the ones in "Starting Forth" on Forth Inc.'s site?

> [...]
> --
> Darin Murphy

I'm an outsider, and I'd noticed the issue about Starting Forth, myself.

gforth does get about as close as possible, I think.

And I was surprised that Anton didn't suggest some method of fixing the numeric parsing to accept the alternate flag characters for double-length integers. It shouldn't be too hard. (Maybe?)

My impression is that Forth is not a language so much as a point of view and a willingness to manage your own symbol tables, and, as you can tell from the responses, it's a very individual point of view. (Lisp has the same kinds of problems.) This is why it's hard to get a truly standard Forth.

Which means that not having a Forth that is completely compatible with the Starting Forth book may be an advantage. It gets you used to having to glue things together yourself.

If you're looking for another free-as-in-software Forth that should run on your pi, -- and _iff_ you are willing to compile it yourself -- you might look at one of my little time-wasters.

(I assume from your comments in the thread you would be comfortable with "cc -Wall -o executablename *.c", or with using make.)

One of them, I call bif-c for reasons that are too arcane and personal to explain, although I mention them somewhere in the pseudo-documentation. I know it compiled on an embedded SH-3 platform about three years ago. (gcc)

It's a near pre-'83 fig-Forth with some custom stuff I had to add for a couple of college classes I used it in back around '87. I wrote the original in M6809 assembler, and the original source is in the tarball. (The 6809 version is the one I passed the classes on.)

I converted it to C somewhere around the beginning of the millennium when I had too much train riding time, or something, I don't remember exactly.

It's buggy as a west Texas landfill, and I just punted on the DOES> stuff.

And the issue of what is where seriously embarrasses me. You'll have to use grep to find things.

But it does handle a lot of the Starting Forth code. I tried the double flags, and it doesn't recognize commas, but it does recognize hyphens and solidus as flags for double integers. And I'll warn you again, it does miss other things.

With those caveats, you can get the source at:

https://sourceforge.net/projects/bif-c/

Don't grab the so-called release from files, go to the code and get trunk for the latest (r52). In other words, hit the "download snapshot" link on this page:

https://sourceforge.net/p/bif-c/code/HEAD/tree/

More recently, just for fun, I transcribed a very primitive early fig-Forth for 6800. It's available as part of my 6800 assembler stuff, also on sourceforge:

https://sourceforge.net/projects/asm68c/

Again, if you try this, you'll want the snapshot.

It is definitely missing stuff for Starting Forth, but you have the advantage of having fairly readable assembly language source to tinker with.

But it is missing disk primitives.

It runs rather well on Joe Allen's 6800 emulator, well enough that I have not bothered to write my own emulator:

https://sourceforge.net/projects/exorsim/

You'll have to compile that, too, but I think it should run on the pi.

If I could get his attention and get him to show me how to get into the disk emulation parts, or if I could take enough time to figure it out myself, I'd write some disk primitives. I was working on in-RAM emulation that sort-of worked (but provided no access to actual files), the last time I set it down.

[Darin Murpy]

Joel, thanks for taking the time to reply to my post! It's nice to meet
you!

joel...@gmail.com wrote:

> On Sunday, April 2, 2017 at 1:10:44 AM UTC+9, Darin Murphy wrote:
> I'm an outsider, and I'd noticed the issue about Starting Forth, myself.

Outsider? Sounds like you've been in Forth for sometime. Wonder what a
person has to do to become an insider (e.g., write their own forth,
write forth libraries, burn an effigy of Bjarne Stroustrup, etc.,)?
LOL!!!

> gforth does get about as close as possible, I think.

Yeah it's gotten me through and up to Chapter 10. Still going over it. I
like taking my time and I have been busy being a caregiver too!

> My impression is that Forth is not a language so much as a point of view and a willingness to manage your own symbol tables, and, as you can tell from the responses, it's a very individual point of view. (Lisp has the same kinds of problems.) This is why it's hard to get a truly standard Forth.

I think Forth is really the first real Meta-Lanugage in that everything
is a macro built upon primatives, which were built from either
machine code, assembly, or C.

> Which means that not having a Forth that is completely compatible with the Starting Forth book may be an advantage. It gets you used to having to glue things together yourself.

I really don't buy that. I believe the reason Starting Forth doesn't
match up in many ways any modern Forth has more to do with a larger
problem I've observed in Software in general that is either free or
outside the main stream. That is lack of desire to do the boring work.
It's fun to build and tinker with your creations, but it's sooo boring
to document and update your documents about said software, so they
don't. Once I get enough experience programming in Forth and revisit
Assembly, I'll write a forth that fits the "Starting Forth" book letter
by letter just so that new comings can have their own text for Forth and
the heck with the other Forths out there since they cannot given
maintain their compatability with a book they endorse on their Forth
webpages.

>
> If you're looking for another free-as-in-software Forth that should run on your pi, -- and _iff_ you are willing to compile it yourself -- you might look at one of my little time-wasters.

Thanks I might do that after I'm finished with studying Forth and
revisiting Assembly (It's been decades since I've work in Assembly, so
it's going to be a bit!).


Thanks again for your suggestions and advice! Take care now,

Darin Murphy

[Albert van der Horst]

In article <lvOFA.923738$Pm3.2...@fx42.am4>,

Well, no. Marcel Hendrix has done that boring work all right.
He claims the new Starting Forth works on some Forth's because
he *actually tested it there*. Because his work and those Forth's are
based on the 94' standard, it is far from accidental that gForth
is a good match. The authors of gForth go to great lengths
to supply a standard compliant Forth too.

Now writing a Forth that works 100% with the original Starting Forth
is a waste of time, but everybody does as he pleases, of course.

And I agree with the point you're responding to. You want to pamper
the readers of the original Starting Forth like a mother that sees
to it that no bacteria comes neir their child. The first time the
child goes outside the house a bug kills him. Counterproductive.

<SNIP>

>Thanks again for your suggestions and advice! Take care now,
>
>Darin Murphy
>

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

[Andrew Haley]

joel...@gmail.com wrote:

> My impression is that Forth is not a language so much as a point of
> view and a willingness to manage your own symbol tables, and, as you
> can tell from the responses, it's a very individual point of
> view. (Lisp has the same kinds of problems.) This is why it's hard
> to get a truly standard Forth.

You could say the same about LISP, that's true. But in both languages
there is a common standard, and many versions, some standard-
compliant, some not. Truly standard Forth's aren't unusual.

Andrew.

[Elizabeth D. Rather]

On 4/7/17 5:46 AM, Darin Murphy wrote:
>> Which means that not having a Forth that is completely compatible with the Starting Forth book may be an advantage. It gets you used to having to glue things together yourself.
> I really don't buy that. I believe the reason Starting Forth doesn't
> match up in many ways any modern Forth has more to do with a larger
> problem I've observed in Software in general that is either free or
> outside the main stream. That is lack of desire to do the boring work.
> It's fun to build and tinker with your creations, but it's sooo boring
> to document and update your documents about said software, so they
> don't. Once I get enough experience programming in Forth and revisit
> Assembly, I'll write a forth that fits the "Starting Forth" book letter
> by letter just so that new comings can have their own text for Forth and
> the heck with the other Forths out there since they cannot given
> maintain their compatability with a book they endorse on their Forth
> webpages.

The important reason for not using Starting Forth as an introduction to
Forth is that it portrays a very primitive system that will be
unattractive to programmers interested in serious programming, an
impression that is enhanced by its cute cartoons. For example, using
blocks for source and data was an attractive option when many Forths ran
standalone without a host OS, for example, but is a turnoff to
programmers who prefer their own programming editors. And ITC is simple
to implement, but slower than the optimizing Forths that can be found in
increasing numbers (particularly when the ITC Forth is implemented in
C), thus leading to the impression that Forth is too slow for
professional work. Forth was designed for serious application
programming, and has been used successfully that way right along. It
should not be presented as a toy.

[Darin Murpy]

Elizabeth D. Rather wrote:

> The important reason for not using Starting Forth as an introduction to
> Forth is that it portrays a very primitive system that will be
> unattractive to programmers interested in serious programming, an
> impression that is enhanced by its cute cartoons. For example, using
> blocks for source and data was an attractive option when many Forths ran
> standalone without a host OS, for example, but is a turnoff to
> programmers who prefer their own programming editors. And ITC is simple
> to implement, but slower than the optimizing Forths that can be found in
> increasing numbers (particularly when the ITC Forth is implemented in
> C), thus leading to the impression that Forth is too slow for
> professional work. Forth was designed for serious application
> programming, and has been used successfully that way right along. It
> should not be presented as a toy.
>
> Cheers,
> Elizabeth
>

Thank you Mrs. Conklin/Rather posting your opinion. I just did a google
search, looking for reviews of "Starting Forth" and there are a lot of
them and most of them are 4 to 5 out of 5. From reading them, many read
"Starting Forth" in college for a class and they found it both
entertaining and informative. Most of the reviews I've read from
GoodReads, Amazon, Barns & Nobels, were in 2000+, which isn't bad for a
book that was written in the 80s. Many reviewers mentioned that this
was there introduction to stack based languages and many said "Starting
Forth" was the standard, which means that to most of the world this book
reflects Forth. As such I think that either this book should be updated
to reflect the more modern Forth or a more Forth should be built to
reflect "Starting Forth"'s interpretation for Educational purposes. Then
perhaps this would help increase potential programmers moving on to more
complex and modern forths afterwards, which would be good for all
Forthers. Just a thought.

[Darin Murpy]

Thanks for posting your views. Would you happen to have a list of "Truly
standard Forths", because I've checked out gForth, swift Forth, eforth,
CameForth, 4e4th, Win32Forth and none of them are "Truly standard
Forths". Some are mostly complaint, but none are 100%, which is how I
under "Truly" to mean. Thanks again.

[Darin Murpy]

Albert van der Horst wrote:

> Well, no. Marcel Hendrix has done that boring work all right.
> He claims the new Starting Forth works on some Forth's because
> he *actually tested it there*. Because his work and those Forth's are
> based on the 94' standard, it is far from accidental that gForth
> is a good match. The authors of gForth go to great lengths
> to supply a standard compliant Forth too.
>
> Now writing a Forth that works 100% with the original Starting Forth
> is a waste of time, but everybody does as he pleases, of course.
>
> And I agree with the point you're responding to. You want to pamper
> the readers of the original Starting Forth like a mother that sees
> to it that no bacteria comes neir their child. The first time the
> child goes outside the house a bug kills him. Counterproductive.
>
> <SNIP>
>
>>Thanks again for your suggestions and advice! Take care now,
>>
>>Darin Murphy
>>

Thank you Albert for explaining your view in regards to having a 100%
"Starting Forth" complaint Forth built for educational purposes. I would
n't say I want to pamper or sterialize anyone from harnish of reality. I
only understand from my own experiences that learning usually faster
and easier if the documentation (i.e., tutorials, books, classes,
etc.,) are both accurate and entertaining. Also after reviewing dozens
of book reviews about "Starting Forth" from professionals in the field,
students and hobbiest, I am not alone in this. Thanks again for taking
the time to explain your own understandings.

[Julian Fondren]

On Friday, April 7, 2017 at 3:48:40 PM UTC-5, Darin Murphy wrote:
> Andrew Haley wrote:
>
> > joel...@gmail.com wrote:
> >
> >> This is why it's hard
> >> to get a truly standard Forth.

Oh no, someone on clf has expressed a concern with standards!

Is this concern real, or is it a delusion based on problems that the poster
himself has defined into existence, with no assistance from ANS Forth?

So far a good 90% of such problems are of the latter category...

> >
> > You could say the same about LISP, that's true. But in both languages
> > there is a common standard, and many versions, some standard-
> > compliant, some not. Truly standard Forth's aren't unusual.
> >
> > Andrew.
>
> Thanks for posting your views. Would you happen to have a list of "Truly
> standard Forths", because I've checked out gForth,

That's one.

> swift Forth,

That's another.

> eforth,
> CameForth, 4e4th,

Of of these says it is, the others don't say - so probably aren't.

> Win32Forth

That's another. So at least 3/6 of these are standard Forths.

> and none of them are "Truly standard
> Forths". Some are mostly complaint, but none are 100%, which is how I
> under "Truly" to mean. Thanks again.

Yep, it's a delusion again. Probably something like "there are extra words!"

Thanks for helpfully defining 'truly' as '100%'. Anyone confused about
the one is certain to be enlightened by the other.

[Elizabeth D. Rather]

We did look seriously into a truly updated Starting Forth several years
ago, but the effort would have been considerable, and we still felt that
the approach, while friendly and entertaining to young people and
hobbyists would still be off-putting to serious programmers, too many of
whom see Forth as a toy as it is. I strongly recommend that you review
some of the more recent Forth books available from various sources.

Cheers,
Elizabeth

--
Elizabeth D. Rather

[Elizabeth D. Rather]

I'd be interested to know in what ways swiftForth is non-standard
(bearing in mind that not all words in CORE-EXT and optional wordsets
are required in order for a system to be Standard). I believe gForth and
Win32Forth also strive to be standard.

Thanks,

[Darin Murpy]

Elizabeth D. Rather wrote:
>
> I'd be interested to know in what ways swiftForth is non-standard
> (bearing in mind that not all words in CORE-EXT and optional wordsets
> are required in order for a system to be Standard). I believe gForth and
> Win32Forth also strive to be standard.
>
> Thanks,
> Elizabeth
>

I'm sorry Mrs. Conklin/Rather, but how can Swiftforth, and Gforth be
standard and yet not work with "Starting Forth" which is also supposed
to be written in Standard Forth? This is rather confusing. If they are
all "Truly" standard Forth, shouldn't they all be 100% compatible? If
not than what does "Standard Forth" exactly mean? I am not trying to be
sound rude or trolling, just confused about how something can be
standard and pass all of the tests and yet not be compatible with a
book that has been setting the standard for the last 36 years? Anyway
it's cool, I'm not upset about it. Really I'm not. I just think that
for people who are not professional programmers, who are interested in
learning Forth for whatever reason, should have a book like "Starting
Forth" and a verion of Forth that works completely with the book, so
that they can at least follow the instructions without becoming
frustrated with them. That's all. Anyway, thanks for taking the time
to try and clarify somethings for me. Take care now,

Darin Murphy

[rickman]

I agree with you 100%. When learning a new topic of any sort, errors in
the instructional material is often a fairly large pothole in the road.
No only do you have to recognize it as a pothole rather than bad driving
steering the car up onto the curb, you then have to go back to see what
could have been done to avoid hitting the pothole and eventually find a
way to drive around it.

I thought I'd try running the code you are talking about and found a
problem before I even got going. On installation, the readme file says,
"To start the system, just say `gforth'". Well, I have said 'gforth'
until I'm blue in the face and it doesn't run. I tried typing it into a
command window and get "'gforth' is not recognized as an internal or
external command, operable program or batch file." I guess I have to
add the gforth installation directory to the command path...

Ok, did that and now it complains, "gforth: cannot open image file
gforth.fi in path
.:/usr/local/lib/gforth/site-forth:/usr/local/share/gforth/site-forth:/usr/local/lib/gforth/0.7.0-20081226:/usr/local/share/gforth/0.7.0-20081226
for reading"

I don't know what this means, so I will have to come back to this later.
Certainly I could download a newer version. I didn't realize I had
never installed gforth on this machine.

I will need to come back to this when I have more time... :(

--

Rick C

[Elizabeth D. Rather]

That's why I'm asking what things you find "non-Standard". Starting
Forth was brought into closer conformance with ANS Forth than the
original versions (1982 and 1986), but still differs from current
Standards and contemporary practice in many ways. For example, it
requires source code to be in blocks, which is has not been a
requirement for many years; the Blocks wordset is optional. It also
implies an indirect-threaded implementation, which is not required by
any Standard since Forth82, and assumes things about the use of the
Return Stack which are specifically warned against in ANS Forth and
current standards. And I think people whose interest is only casual
should be able to take advantage of modern computing environments.

Cheers,

[rickman]

On 4/1/2017 4:37 PM, Darin Murphy wrote:
>
> Thanks for replying so quickly. Octal was the only word missing in
> gforth in that chapter, but there were other issues with gforth
> following chapter 7. The number examples: 12,345, 12/31/80 and
> 999-6784 both cause "Undefined Word" error in gForth. Only 12.
> will create a double on the stack. The number example $200.00
> creates the double 131072 0 on TOS. The only example that works
> is 12. or 0. Also in the later chapters there are other
> compatibilities and missing words too, but I don't have time
> right now to pick through all of them.

Has anyone looked at the text in Starting Forth regarding these issues?
I can't find anyplace in the text where they ask you to enter 12,345,
The only place I find 12/31/80 is where they are talking about *output*,
not input. The book does talk about entering 999-6784 on the command
line. After digging around in the standard and in Starting Forth, I
realized the book doesn't say these examples can be entered in *any*
system.


**************

Some Forth implementations (including SwiftForth) will convert any
number that contains the following characters as a double number:
+ , - . / :

**************

So this particular shortcoming is about the book, not the Forths. Is
there a way to load in some code that will make the examples work?


I would also mention that the PDF copy of Starting Forth containing
links to go to the various chapters does not take you to the chapters in
the document, they take you to the webpage on the Forth Inc web site. I
expect this is well known, but I wasn't aware of it. There is another
PDF copy of the book, but it simply has no links at all.

--

Rick C

[Darin Murpy]

rickman wrote:
>
> Has anyone looked at the text in Starting Forth regarding these issues?
> I can't find anyplace in the text where they ask you to enter 12,345,
> The only place I find 12/31/80 is where they are talking about *output*,
> not input. The book does talk about entering 999-6784 on the command
> line. After digging around in the standard and in Starting Forth, I
> realized the book doesn't say these examples can be entered in *any*
> system.
>
>
> **************
>
> Some Forth implementations (including SwiftForth) will convert any
> number that contains the following characters as a double number:
> + , - . / :
>
> **************
>
> So this particular shortcoming is about the book, not the Forths. Is
> there a way to load in some code that will make the examples work?
>
>
> I would also mention that the PDF copy of Starting Forth containing
> links to go to the various chapters does not take you to the chapters in
> the document, they take you to the webpage on the Forth Inc web site. I
> expect this is well known, but I wasn't aware of it. There is another
> PDF copy of the book, but it simply has no links at all.
>

Hey Rickman,

The numbers I am referring are located in 7. A Number of Kinds of
Numbers, under Number Formatting — Double-length Unsigned.

For instance the UD. word in GForth and the UD. word that your
instructed to create to convert 12,345 return the error that 12, is not
a defined word. Later down in the chapter it saids:

Now let's say we have a phone number on the stack, expressed as a double-length unsigned integer. For example, we may have typed in:

999-6784

(remember that the hyphen tells NUMBER to treat this as a double-length
value). We want to define a word that will format this value back as a
phone number.

This number too will return an error message in Gforth.

Now as I was telling Mrs. Conklin/Rather, I'm not upset or trying to
cause any trouble by bringing this information up, only that I think
that if there was a Forth created, say for education that worked 100%
with "Starting Forth", that it would really help new comers (perhaps not
experienced programmers) to learn and enjoy Forth for themselves.

[Darin Murpy]

Elizabeth D. Rather wrote:

> That's why I'm asking what things you find "non-Standard". Starting
> Forth was brought into closer conformance with ANS Forth than the
> original versions (1982 and 1986), but still differs from current
> Standards and contemporary practice in many ways. For example, it
> requires source code to be in blocks, which is has not been a
> requirement for many years; the Blocks wordset is optional. It also
> implies an indirect-threaded implementation, which is not required by
> any Standard since Forth82, and assumes things about the use of the
> Return Stack which are specifically warned against in ANS Forth and
> current standards. And I think people whose interest is only casual
> should be able to take advantage of modern computing environments.
>
> Cheers,
> Elizabeth
>

Oh so basically the new standard has changed enough that the standard
that "Starting Forth" uses is no longer valid. Okay, that makes sense.
Thank you, Mrs. Conklin/Rather for explaining it to me better. Now, I
understand why there is a difference. I know about the Forth83 and even
the 94 standard, but didn't know it's be updated again. I just checked
and I see it's 2012 now? Okay, thank you for the update. LOL!!! Take
care now,

Darin Murphy

[Darin Murpy]

rickman wrote:

> I agree with you 100%. When learning a new topic of any sort, errors in
> the instructional material is often a fairly large pothole in the road.
> No only do you have to recognize it as a pothole rather than bad driving
> steering the car up onto the curb, you then have to go back to see what
> could have been done to avoid hitting the pothole and eventually find a
> way to drive around it.
>
> I thought I'd try running the code you are talking about and found a
> problem before I even got going. On installation, the readme file says,
> "To start the system, just say `gforth'". Well, I have said 'gforth'
> until I'm blue in the face and it doesn't run. I tried typing it into a
> command window and get "'gforth' is not recognized as an internal or
> external command, operable program or batch file." I guess I have to
> add the gforth installation directory to the command path...
>
> Ok, did that and now it complains, "gforth: cannot open image file
> gforth.fi in path
> .:/usr/local/lib/gforth/site-forth:/usr/local/share/gforth/site-forth:/usr/local/lib/gforth/0.7.0-20081226:/usr/local/share/gforth/0.7.0-20081226
> for reading"
>
> I don't know what this means, so I will have to come back to this later.
> Certainly I could download a newer version. I didn't realize I had
> never installed gforth on this machine.
>
> I will need to come back to this when I have more time... :(
>

Rick, sorry but I cannot tell whether you are making fun on what I said,
trying to make a point, or if you are seriously having this much of an
issue getting gforth installed on Linux. If it's the latter, I'm sorry,
but I was able to get it working just by typing:

sudo apt-get install gforth

Then when it finished installing it, I open a terminal window and typed:

gforth

Which started up find. I've been using the Gforth manual with "Starting
Forth" in tandem, so I can maximumize my understanding of the subject
and try to understand how to avoid some of the pot holes, although it's
as you said earlier, with out know what is a pot-hole and what is bad
steering, it can make it frustrating trying to learn how to drive.
Anyway thanks for pointing things out and if you were trying to joke
LOL. Take care now,

Darin Murphy

[rickman]

On 4/1/2017 12:10 PM, Darin Murphy wrote:
> Hey everybody!
>

> It's been a very, very long time since I posted on this site. Was
> away from Forth for 6 months trying to go to UOPeople, which
> wasn't what I expected. I started back up with Forth in Dec 2016
> and nearly finished with "Starting Forth". I like taking my time
> to make sure I understand things very well and have already made
> a much of small trivial programs outside of the book, including
> one that was a tiny rogue game using a only 1 dimensional array
> as the screen buffer. It was a blast!

Rather than just reading the posts and taking everything for granted, I
finally did some digging. I realize now what the problem is. Starting
Forth is *not* 100% compatible with all standard Forths. This is a flaw
in the book that Ms Conklin has explained in a recent post in this thread.

In reading some of your more recent posts I see you are assuming that
Starting Forth *must* be 100% standard. But it is *not*. Ms Conklin
points out some of the issues.

> Anyway, I've stumbled upon an issue with the book and was
> wondering if someone knew where I can find a free forth that
> works with my Raspberry Pi and uses all of the same exact words

> as the ones in "Starting Forth" on Forth Inc.'s site? I
> understand it's a tall order, but just thought I'd ask. I've
> already tried 4e4th, which is a great little Forth that runs on a
> MSP430, but it's so small that it's missing a lot of words (i.e.,
> missing all of Chapter 3 words).

Chapter 3 is called "The Editor (and Staff)" which makes me think it
originally included a description of a line editor. I can't find my
printed copy or I would check. In any event, the point is most of that
chapter is obsolete. I know there is at least one Forth system that
still uses blocks, the Forth system used for developing code for the
GA144. Otherwise I think they are few and far between. So don't worry
about chapter 3.


> I've also tried gForth which has
> a crazy amount of words, and has gotten me successfully up to
> Chapter 7, but than it too is missing a bunch of words that are
> in the book.

About the word OCTAL, the book says, "OCTAL ( -- ) Sets the base to
eight (available on some systems)". That is a clear indication you
should not assume it is part of the Forth standard. As I mentioned in
my other post, the number formats used for double words in the book are
not universal. What else does not work from Chapter 7?


> I've been able to get most of Chapter 8, and 9 done
> and now working on Chapter 10. Whew it's been a awesome
> adventure! Forth is actually better than I initially thought and
> I can't wait to see what I learn next about it. Once I've
> finished both "Staring Forth" and "Thinking Forth" and gotten
> some experience under my belt I'll be moving on to ARM Assembly.
> Having those two under my belt is going to be blast!

If you like ARM assembly, you will LOVE Mecrisp, a Forth for a number of
embedded MCUs including a number of ARM processors. Written by Matthias
Koch almost entirely in assembly it allows you to run Forth directly on
rather small processors. What you won't love is the lack of
documentation. But if you know German you can read all of the code
comments (some are English, some German) and easily learn how it all
works (well, more easily that I did having to look up a lot of technical
terms in German which isn't so easy to do).

There is a Mecrisp documentation site at http://128.199.141.78/ by Terry
Porter. Yes, it is just an IP address without a URL. I don't know why
he prefers that, but there it is. This is probably the best
documentation available. I've created a domain name that points to his
main page. armforth.org

I've used the TI Stellaris launchpad (not sure what they call it now but
Steallaris was the chip line that was bought by TI for their low end
ARMs) and can help if you would like. Terry uses the STmicro ARMs. If
you want to use their boards he can be a great resource.

--

Rick C

[rickman]

I get what you are saying, but Ms. Conklin has already indicated why
they don't want to improve or promote the book, Starting Forth. It is
not professional looking enough for the business aspects of Forth, Inc.
They have a couple of books that they offer which are more in line with
their ideas.

I seriously doubt anyone is going to develop a special Forth just for
Starting Forth. But once you are done with that and the other books you
are reading, maybe you could come up with a package which can be loaded
into one of the existing forths to make it adequately compatible for
someone to use Starting Forth (other than chapter 3 perhaps)?

I haven't read the entire thread in detail, but the two things I found
you discuss were the missing word OCTAL and the lack of accepting some
of the special characters in double numbers. Ignoring chapter 3, what
else have you found?

--

Rick C

[rickman]

No, I'm not making fun of you. I'm using Windows. gForth will run
under Windows and I believe I've done that, but it must have been on my
last laptop.

I normally use Win32Forth which is a nice package. I have used it
professionally for a test fixture I developed to production test boards
I sell. I got some help from Jos in the Yahoo group and it even copies
some data to the Windows paste buffer to make pasting it into a spread
sheet that much easier!

> Then when it finished installing it, I open a terminal window and typed:
>
> gforth
>
> Which started up find. I've been using the Gforth manual with "Starting
> Forth" in tandem, so I can maximumize my understanding of the subject
> and try to understand how to avoid some of the pot holes, although it's
> as you said earlier, with out know what is a pot-hole and what is bad
> steering, it can make it frustrating trying to learn how to drive.
> Anyway thanks for pointing things out and if you were trying to joke
> LOL. Take care now,

I have a raspberry pi which is not connected to anything at the moment.
I've run gForth on that ok. But I don't feel like getting it up and
running as that means I have to use Putty or something on the PC to talk
to it. I did a small project on the TI Stellaris ARM launchpad this way
a couple of years ago and it worked well. But I don't recall all the
details of getting it set up and talking to it over the network.

Still, I found the same issues with Win32Forth, but they aren't the
fault of the Forth package. The book Starting Forth has never been
brought up to modern usage 100%. Then there are a few examples they use
that they *say* will not run on all systems verbatim. For the double
numbers, just use a period instead of the slashes or hyphens and the
number will be accepted.

--

Rick C

[David Schultz]

On 04/07/2017 08:31 PM, rickman wrote:
> If you like ARM assembly, you will LOVE Mecrisp, a Forth for a number of
> embedded MCUs including a number of ARM processors. Written by Matthias
> Koch almost entirely in assembly it allows you to run Forth directly on
> rather small processors.

ARM assembly isn't too bad but I am developing a deep hatred of the
Thumb mode bit. It reminded me of the book "The Soul of a New Machine"
so I dug up my copy and started to re-read it.

I ported over the version of eForth I had developed for the MSP430 which
went smoothly enough except for keeping track of when that damn mode bit
should and shouldn't be set. You would think that a processor that is
exclusively Thumb mode would ignore that bit. It doesn't.

--
David W. Schultz
http://home.earthlink.net/~david.schultz
"Life without stock is barely worth living..." - Anthony Bourdain

[rickman]

On 4/7/2017 9:50 PM, David Schultz wrote:
> On 04/07/2017 08:31 PM, rickman wrote:
>> If you like ARM assembly, you will LOVE Mecrisp, a Forth for a number of
>> embedded MCUs including a number of ARM processors. Written by Matthias
>> Koch almost entirely in assembly it allows you to run Forth directly on
>> rather small processors.
>
> ARM assembly isn't too bad but I am developing a deep hatred of the
> Thumb mode bit. It reminded me of the book "The Soul of a New Machine"
> so I dug up my copy and started to re-read it.
>
> I ported over the version of eForth I had developed for the MSP430 which
> went smoothly enough except for keeping track of when that damn mode bit
> should and shouldn't be set. You would think that a processor that is
> exclusively Thumb mode would ignore that bit. It doesn't.

Do you mean the MSP432? The MSP430 is not an ARM, it's a totally
separate 16 bit processor by TI. Some say the assembly language is akin
to the PDP/LSI-11.

--

Rick C

[Elizabeth D. Rather]

Forth2012 is not significantly different from Forth94 (ANS Forth), it's
mostly added and clarified some things. In general, the international
standards bodies recommend that standards be reviewed and updated every
5 years or so. I don't think any contemporary programming language has
gone 35 years without significant change.

[David Schultz]

On 04/07/2017 09:04 PM, rickman wrote:
> Do you mean the MSP432? The MSP430 is not an ARM, it's a totally
> separate 16 bit processor by TI. Some say the assembly language is akin
> to the PDP/LSI-11.
>

No. MSP430FR5969 to be precise. The ARM target is the MK66FX1M0 in the
Teensy 3.6.

[Elizabeth D. Rather]

On 4/7/17 3:16 PM, Darin Murpy wrote:
> rickman wrote:
>>
>> Has anyone looked at the text in Starting Forth regarding these issues?
>> I can't find anyplace in the text where they ask you to enter 12,345,
>> The only place I find 12/31/80 is where they are talking about *output*,
>> not input. The book does talk about entering 999-6784 on the command
>> line. After digging around in the standard and in Starting Forth, I
>> realized the book doesn't say these examples can be entered in *any*
>> system.
>>
>>
>> **************
>>
>> Some Forth implementations (including SwiftForth) will convert any
>> number that contains the following characters as a double number:
>> + , - . / :
>>
>> **************

Note the caveat, "*Some* Forth implementations...."

>> So this particular shortcoming is about the book, not the Forths. Is
>> there a way to load in some code that will make the examples work?
>>
>>
>> I would also mention that the PDF copy of Starting Forth containing
>> links to go to the various chapters does not take you to the chapters in
>> the document, they take you to the webpage on the Forth Inc web site. I
>> expect this is well known, but I wasn't aware of it. There is another
>> PDF copy of the book, but it simply has no links at all.
>>
>
> Hey Rickman,
>
> The numbers I am referring are located in 7. A Number of Kinds of
> Numbers, under Number Formatting — Double-length Unsigned.
>
> For instance the UD. word in GForth and the UD. word that your
> instructed to create to convert 12,345 return the error that 12, is not
> a defined word. Later down in the chapter it saids:
>
> Now let's say we have a phone number on the stack, expressed as a double-length unsigned integer. For example, we may have typed in:
>
> 999-6784
>
> (remember that the hyphen tells NUMBER to treat this as a double-length
> value). We want to define a word that will format this value back as a
> phone number.
>
> This number too will return an error message in Gforth.

This is a good example where Starting Forth is really not in agreement
with *any* standard. I'm not sure what edition you're using, but the
only truly Standard way to enter a double integer is with a decimal
point at the trailing end of the string. Different systems may use a
decimal point elsewhere to make a float, and may not allow any other
punctuation. And European Forths commonly accept a comma in a number for
decimal places, since that's standard practice in Europe.

Starting Forth was written by Leo Brodie in 1980-81, published in 1982.
At the time, Leo worked for FORTH, Inc., who paid for the work. Since
the early 70's FORTH, Inc. had followed the practice of allowing
punctuation to cause numbers to be converted as doubles. In those days
virtually all processors had 16-bit cells, so couldn't even handle
things like most zip codes, let alone phone numbers, as single-cell
values, so this was very convenient. However, as Forth became more
popular in the mid-to-late 80's, other developers didn't follow this
practice, and no standard has ever used that rule. Forth, Inc. still
accepts embedded punctuation because many of our users have followed
this practice for so long they would be very upset if we didn't!

> Now as I was telling Mrs. Conklin/Rather, I'm not upset or trying to
> cause any trouble by bringing this information up, only that I think
> that if there was a Forth created, say for education that worked 100%
> with "Starting Forth", that it would really help new comers (perhaps not
> experienced programmers) to learn and enjoy Forth for themselves.

Are there any educational C compilers that slavishly follow Kernigan &
Ritchie's original 1988 book on C?

[hughag...@gmail.com]

On Sunday, April 2, 2017 at 7:46:37 PM UTC-7, Darin Murphy wrote:
> \ Okay Hugh here it is!
>
> \ tiny_arena01.fs
> \ Created by Darin Murphy
> \ Created on 02/24/17
>
> \ Currently the walls of the arena are finished and the player may
> move about the area using the arrow keys
> \ Loads and runs fine from my Raspberry Pi 3 B running gforth
> \ To load up if in linux type: gforth tiny-arena01.fs, then after
> gforth loads type: player-walking.
> \ Eventually it will have monsters spinkled over the arena and
> everytime the player fights one by ramming
> \ into it they will get a score and can die if the monster hurts
> them too much. Fights will be determined
> \ randomly. Had to stop working on it, until I can find a small
> and fast randomizer formula.
>
> 64 constant plyrsymbl \ "@" symbol of player
> 35 constant wallsymbl \ "#" symbol of wall
> 77 constant mnstrsymbl \ "M" symbol of monster
> 32 constant mptyspace \ " " empty space
>
> \ screen array which represents the console screen 80 x 25
> characters or 2000 cells
> variable scrnarry 1999 cells allot
>
> \ fill screen array with empty space " "
> : clear-screen ( -- ) 1999 0 do mptyspace scrnarry i cells + ! loop ;
>
> \ current positon of a mobile unit ( monster/player )
> variable curpos
> 0 curpos ! \ initialize it to 0 for safty
>
> \ previous position of a mobile unit ( monster/player )
> variable prevpos
> 0 prevpos ! \ initialize it to 0 for safty
>
> \ player's position
> variable plyrpos
> 10 80 * 40 + plyrpos ! \ starting position
>
> \ monster's position
> variable mnsterpos
>
> \ used for building room
> variable counter
> 0 counter !
>
> \ health points of player
> variable health
> 10 health !
>
> \ player's score for killing monsters
> variable score
> 0 score !
>
> \ screen array helper words
> : clear-prevpos ( position -- ) mptyspace scrnarry prevpos @ cells
> + ! ;
> : y1- ( -- n ) curpos @ 80 - ;
> : y1+ ( -- n ) curpos @ 80 + ;
> : x1- ( -- n ) curpos @ 1 - ;
> : x1+ ( -- n ) curpos @ 1 + ;
>
> \ copies current position to previous postion
> : curpos>prevpos ( -- ) curpos @ prevpos ! ;
>
> \ scans current position in screen array to determine whether
> mobile unit there is player
> \ or monster
> : get-moversymbl ( -- identity ) scrnarry curpos @ cells + @ ;
>
> \ checking position in screen array
> : look-forward ( -- n ) y1- cells scrnarry + @ ;
> : look-behind ( -- n ) y1+ cells scrnarry + @ ;
> : look-left ( -- n ) x1- cells scrnarry + @ ;
> : look-right ( -- n ) x1+ cells scrnarry + @ ;
>
> \ identifying if there is something/someone at a particular
> position and if so,
> \ who/what are they
> : clear? ( new position -- boolean flag ) mptyspace = ;
> : wall? ( new position -- boolean flag ) wallsymbl = ;
> : monster? ( new position -- boolean flag ) mnstrsymbl = ;
> : player? ( new position -- boolean flag ) plyrsymbl = ;
>
> \ goto postion in screen array
> : goto-position ( symbol -- ) scrnarry curpos @ cells + ! ;
>
> \ moving forward, backward, left, or right entails copying current
> postion to previous position
> \ updating curpos, updating screen array with new location, and
> \ finally removing previous position in screen array
> : move-forward ( -- ) get-moversymbl curpos>prevpos y1- curpos !
> goto-position clear-prevpos ;
>
> : move-backward ( -- ) get-moversymbl curpos>prevpos y1+ curpos
> ! goto-position clear-prevpos ;
>
> : move-left ( -- ) get-moversymbl curpos>prevpos x1- curpos !
> goto-position clear-prevpos ;
>
> : move-right ( -- ) get-moversymbl curpos>prevpos x1+ curpos !
> goto-position clear-prevpos ;
>
> \ before moving to new position, first determine if position is
> clear, if so move there
> : go-forward ( -- n ) look-forward dup clear? if drop
> move-forward else drop
> then ;
>
> : go-backward ( -- n ) look-behind dup clear? if drop
> move-backward else drop
> then ;
>
> : go-left ( -- n ) look-left dup clear? if drop move-left else drop
> then ;
>
> : go-right ( -- n ) look-right dup clear? if drop move-right else drop
> then ;
>
> \ initializing screen array before starting program
> clear-screen
>
> \ update screen from screen array
> : update-screen ( -- ) page 1999 0 do scrnarry i cells + @ emit loop ;
>
> \ Building a large room (takes up the whole screen) by encircling
> it with walls of #
> : north-wall ( -- ) 79 0 do wallsymbl scrnarry i cells + ! loop ;
>
> : estwst-walls ( -- ) 21 0 do counter @ 79 + counter ! wallsymbl
> scrnarry counter @ cells + !
> counter @ 1 + counter ! wallsymbl
> scrnarry counter @ cells + !
> loop 0 counter ! ;
>
> : south-wall ( -- ) 21 80 * counter @ + counter ! 80 0 do
> wallsymbl scrnarry counter @ i + cells + !
> loop 0
> counter ! ;
> : build-arena ( -- ) north-wall estwst-walls south-wall ;
>
> \ build arena, then add player to screen array at starting postion
> build-arena
> plyrpos @ curpos !
> plyrsymbl scrnarry curpos @ cells + !
>
> \ Main loop, which takes player's key input every turn, moves
> player accordingly, refreshes screen too
> \ if player presses the q key then the player wants to quit so the
> loop exits
> : player-walking ( -- ) begin update-screen ekey dup 113 = if
> drop page exit
> else
> dup k-up = if drop go-forward
> else
> dup k-down = if drop go-backward
> else
> dup k-left = if drop go-left
> else
> dup k-right = if drop go-right
> else drop
> then
> then then then then
> again ;
>
> \ Let me know if I need to document further or if I am able to
> factor things better. Take care now.

Well, I wrote my own game based on your game idea. The problem I saw in your code was that you weren't thinking in terms of general-purpose code-libraries --- most likely because "Starting Forth" doesn't discuss the subject --- no Forth Inc. book discusses the subject, and Elizabeth Rather is obsessively opposed to general-purpose code-libraries.

Anyway, the program is not difficult given the novice-package. Also, it is a good idea when writing any program to write a general-purpose code-libraries for the purpose of supporting your program. This allows you to write other similar programs in the future without needing any cut-and-paste coding, which is always bad. Also, doing it this way allows you to abstractify the essential aspects --- this usually clarifies the mind --- this is much better than having general concepts mixed in with application-specific concepts in a big muddle.

Pretty much every time that I write a program in VFX, I find a bug in VFX. This was no exception:

cr .( hello world) 0 0 at-xy .( goodbye!)
hello worldgoodbye! ok

AT-XY isn't working properly.

I got my game to work, but it behaves very weirdly. There are actually two images on the screen, one above the other, both playing the game --- the upper image appears to be one cycle behind the bottom image.

Whenever anything goes wrong with my programs, it is usually the fault of the compiler (VFX) --- I almost never make mistakes, and when I do I find them and fix them, which is called "debugging" --- if problems continue, then it is the compiler, not me.

I'll present the source-code here. Note that this requires the new novice-package because it uses <SWITCH and some other new stuff. I can email a copy to Darin or whoever wants it. Also, I really am going to release the novice-package upgrade soon --- I just get side-tracked with writing code, such as this game, or writing documentation.

Darin should focus on the last section of the code, which is the example game. The rest of the code is the general-purpose code-library I wrote to support games like this. Darin can skim over that code, which is likely above his head, and just learn how to use it without fully learning how it works. After he has used it, such as writing his own game, he can look at it more closely and figure out how it works.
---------------------------------------------------------------------------

\ ARENA.4TH --- derived from tiny-arena01.fs by Darin Murphy --- needs NOVICE.4TH included.

\ This file is a framework that can be used in any char-based game.
\ Put your game in another file.

\ We need to have TICKS defined, which is not ANS-Forth and can't be written in ANS-Forth.

marker arena.4th

VFX? 0= [if]

!!! TICKS is needed!

: ticks ( -- ms ) \ current time in milliseconds
...
;

[then]


\ ******
\ ****** This contains SCREEN which is the array representing the screen.
\ ******

0 \ kinds of elements in the game
enum empty
enum wall \ II
enum ball \ {} \ this could be a ball, such as in BreakOut
enum eyes \ oo \ this could represent the player
enum wide-eyes \ OO \ this could represent the player under duress
enum mouth \ <> \ this could represent a monster
enum horz-bar \ == \ this could represent a bar in a BreakOut game
enum brick \ ## \ this could represent a brick in a BreakOut game
enum treasure \ $$ \ this could represent a bag of money
enum vert-bar \ [] \ this could represent a bar in a Pong game
enum down-spike \ \/ \ this could fall from the top of the screen
enum up-spike \ /\ \ this could shoot up from the bottom of the screen
constant kind-limit

\ We need to have EMPTY and WALL --- the others can be changed --- more can be added if needed.
\ Make sure that LEFT-SYMBOLS and RITE-SYMBOLS are updated too.

\ The suggestions above for what the elements represent will vary from game to game.
\ For example, DOWN-SPIKE and UP-SPIKE could be food that the player needs to consume.

\ The elements are two characters wide (they have a left and a right part).
\ The typical screen width is somewhat over twice the height, so we want wide elements.
\ Otherwise the screen would appear to be stretched out horizontally.

create left-symbols \ must correspond to elements
bl c, \ empty
char I c, \ wall
char { c, \ ball
char o c, \ eyes
char O c, \ wide-eyes
char < c, \ mouth
char [ c, \ horz-bar
char # c, \ brick
char $ c, \ treasure
char = c, \ vert-bar
char \ c, \ down-spike
char / c, \ up-spike

create rite-symbols \ must correspond to elements
bl c, \ empty
char I c, \ wall
char } c, \ ball
char o c, \ eyes
char O c, \ wide-eyes
char > c, \ mouth
char ] c, \ horz-bar
char # c, \ brick
char $ c, \ treasure
char = c, \ vert-bar
char / c, \ down-spike
char \ c, \ up-spike

: check-element ( element -- element )
dup 0< abort" *** SYMBOL given negative element ***"
dup kind-limit >= abort" *** SYMBOL given too large element ***"
;

: symbol ( element -- rite-char left-char )
check-element
dup rite-symbols + c@
swap left-symbols + c@ ;

35 constant horz \ horizontal size of screen \ half of display screen
25 constant vert \ vertical size of screen

\ HORZ is half of the display screen because the elements are two chars wide.
\ HORZ should not be the full screen because the CR in <DISPLAY-SCREEN> would be redundant.
\ HORZ is less than the full screen so there is a margin on the right edge for data (score, clock, etc.).

horz 2 / constant cx
vert 2 / constant cy \ CX and CY are the center of the screen

c 0 horz vert ary screen \ 0 0 is the upper-left corner

-1 constant up
1 constant down

-1 constant left
1 constant rite

\ It is traditional in games that 0 0 is the upper-left corner, not the lower-left corner like in Cartesian coordinates.
\ UP and DOWN would seem to be backwards for somebody who is assuming the first quadrant in Cartesian coordinates.

: traverse-screen { 'element -- } \ 'ELEMENT ( col col-adr -- )
vert 0 do
<screen I -> \ -- row-adr
horz 0 do
I \ -- row-adr col
over I screen> \ -- row-adr col col-adr
'element execute \ -- row-adr
loop
drop \ --
loop ;

: <clear-screen> ( col col-adr -- )
empty swap c!
drop ;

: clear-screen ( -- ) \ fills SCREEN with EMPTY SYMBOL
['] <clear-screen> traverse-screen ;

: <display-screen> ( col col-adr -- )
c@ symbol emit emit \ -- col
horz 1- = if cr then
;

: display-screen ( -- ) \ displays SCREEN on the display screen
0 0 at-xy
['] <display-screen> traverse-screen ;


\ ******
\ ****** This contains ERASE-BOX and DRAW-BOX for drawing obstacles.
\ ******

: <draw-box> { width height lx uy kind | rx dy -- } \ KIND is typically WALL or EMPTY
lx width + 1 - to rx \ RX is right-X, LX is left-X
uy height + 1- to dy \ UY is upper-Y, DY is lower-Y
rx lx ?do
kind I uy screen c! \ up edge
kind I dy screen c! \ down edge
loop
dy uy ?do
kind lx I screen c! \ left edge
kind rx I screen c! \ right edge
loop
kind rx dy screen c! ; \ left-down corner was not done in the loops above

: erase-box ( width height lx uy -- ) \ LX UY is the upper-left corner
empty <draw-box> ;

: draw-box ( width height lx uy -- ) \ LX UY is the upper-left corner
wall <draw-box> ;

\ DRAW-BOX is typically done during initialization, so it doesn't have to be efficient.
\ The assumption is that boxes don't move around during the game.
\ If they do move, use ERASE-BOX to get rid of the old box, then DRAW-BOX to install the new box.


\ ******
\ ****** This contains PLAY-GAME that executes the user's code peiodically and exits on ESC.
\ ******

300 value cycle \ how many milliseconds per cycle

variable cycles \ how many full cycles have passed \ this needs to be initialized to 0

27 constant <esc> \ the ascii for the ESC key

: elapsed ( start-time -- time )
ticks swap - ;

: cycled? ( start-time -- flag )
elapsed cycle > ;

: cursor-beyond ( -- )
horz vert at-xy cr ;

: play-game ( 'cycle -- ) \ 'CYCLE ( char|false -- str|false )
ticks false \ -- 'cycle start-time char|false
begin dup <esc> <> while
rover execute \ -- 'cycle start-time str|false
display-screen \ -- 'cycle start-time str|false
?dup if
cursor-beyond count type
2drop exit then
dup cycled? abort" *** the 'CYCLE code took too long ***"
begin dup cycled? until
1 cycles +!
cycle + \ -- 'cycle new-start-time
key? if key else false then \ -- 'cycle new-start-time char|false
repeat
cursor-beyond ." ESCAPE"
3drop ;

\ PLAY-GAME calls 'CYCLE every CYCLE milliseconds giving it the most recent keypress.
\ PLAY-GAME exits if the ESC key is pressed, so ESC can't be part of the game user-interface.

\ If the key is held down, there is a delay, then it begins to repeat --- this is very clumsy.
\ It is best for the player to just tap the key rather than hold it down.
\ The direction indicated by the key will continue to be in effect until another key is tapped.


\ ******
\ ****** This contains OBJECT and some support code.
\ ******

list \ these are objects in the game, other than WALL or EMPTY
w field .kind \ kind of element displayed
w field .x
w field .y \ coordinates of location
w field .dx
w field .dy \ offset to move
constant object

\ An offset is one of: -1 0 1

: init-object ( x y kind node -- node )
init-list >r
r@ .kind !
r@ .y !
r@ .x !
0 r@ .dy !
0 r@ .dx !
r> ;

: new-object ( x y kind -- node )
object alloc
init-object ;

: kill-object ( node -- )
dealloc ;

: draw-object { node -- }
node .kind @
node .x @ node .y @ screen c! ;

: erase-object { node -- }
empty
node .x @ node .y @ screen c! ;

: collision? { nodeA nodeB -- flag }
nodeA .x @ nodeB .x @ <> if false exit then
nodeA .y @ nodeB .y @ <> if false exit then
true ;


\ ******
\ ****** This contains SEEK and MOVE-OBJECT and some support code.
\ ******

300 value severe \ how many full cycles pass before the monsters totally zero in on the player
\ if CYCLE is 100 then a SEVERE of 1000 would be 10 seconds

: tweak-offset ( offset -- new-offset ) \ randomly tweaks the offset
cycles @ severe bias < if
?dup if negate
else 1 rnd 2 * 1 - then
then ;

: seek { monster goal -- } \ sets the .DX .DY offsets for the monster
goal .x @ monster .x @ - sgn tweak-offset monster .dx !
goal .y @ monster .y @ - sgn tweak-offset monster .dy ! ;

\ When CYCLES is low (early in the game) the chance of it being < the RND value is high, so the monster changes direction.
\ As the game progresses, the chance decreases, so the monster is increasingly likely to stay aimed at the player.
\ When CYCLES reaches SEVERE the chance is zero, so the monster is totally focused on the player.
\ When changing direction, if the direction is -1 or 1 then the direction becomes opposite.
\ If the direction is zero then we randomly choose -1 or 1 as the new direction.

\ We need INIT-SEED called in the initialization, because TWEAK-OFFSET uses RND above.

: move-object { node -- } \ needs .DX .DY set, adjusts .X .Y \ doesn't move into WALL
node .x @ node .dx @ + \ -- x
node .y @ node .dy @ + \ -- x y
2dup screen c@ wall = if
2drop \ leave object unmoved if there is a WALL in front of it
else
node .y ! node .x ! \ move object, possibly running into another object
then ;


\ ******
\ ****** This is a small example game --- it is kept simple for educational purposes.
\ ****** The player has to run over all the treasures before the monsters run over him.
\ ****** The player is displayed eyes oo early in the game, then becomes wide-eyes OO as the monsters' aggression increases
\ ****** The monsters are mouths <> and the treasures are money-bags: $$
\ ****** Initially the monsters are biased to moving away from the player, but increasingly
\ ****** become biased to moving toward the player. At SEVERE full cycles they totally go after the player.
\ ****** Anybody writing a game should put it in another file, unless it is a direct upgrade of this game.
\ ******

variable treasures \ list of treasures
variable monsters \ list of monsters
variable player \ the player

: <guide-player> ( dx dy -- ) \ sets the .DX .DY offsets for the player
player @ .dy !
player @ .dx ! ;

<switch \ PLAY-GAME also uses the <ESC> key to escape
:noname drop 1 0 <guide-player> ; char l swof \ right
:noname drop -1 0 <guide-player> ; char k swof \ left
:noname drop 0 -1 <guide-player> ; char q swof \ up
:noname drop 0 1 <guide-player> ; char a swof \ down
:noname drop ; fast-switch> guide-player ( char|false -- )

: init-obstacles ( -- ) \ assumes CLEAR-SCREEN already done
horz vert 0 0 draw-box \ border
1 7 cx 2 - cy 3 - draw-box \ left rail
1 7 cx 2 + cy 3 - draw-box \ right rail
4 7 cx 11 - cy 7 - draw-box \ left box
4 7 cx 8 + cy 1 + draw-box \ right box
;

: init-treasures ( -- node )
0
cx cy treasure new-object link \ center treasure
cx 5 - cy 3 - treasure new-object link \ left treasure
cx 5 + cy 3 + treasure new-object link \ right treasure
;

: init-monsters ( -- node )
0
cx 5 - cy 7 - mouth new-object link \ upper-left monster
cx 5 - cy 7 + mouth new-object link \ upper-right monster
cx 5 - cy 3 + mouth new-object link \ middle-left monster
cx 5 + cy 3 - mouth new-object link \ middle-right monster
cx 5 + cy 7 - mouth new-object link \ lower-left monster
cx 5 + cy 7 + mouth new-object link \ lower-right monster
;

: init-player ( -- node )
1 1 eyes new-object ;

: init-game ( -- )
page
1 seed ! \ init-seed
0 cycles !
clear-screen
init-obstacles
init-treasures dup treasures ! ['] draw-object each
init-monsters dup monsters ! ['] draw-object each
init-player dup player ! draw-object
display-screen ;

: maybe-remove-treasure { node -- } \ NODE must be in the TREASURES list
node player @ collision? if
treasures @ node remove \ -- new-head node
dup erase-object kill-object \ -- new-head node
treasures ! then ;

: taken-all-treasure? ( -- flag )
treasures @ ['] maybe-remove-treasure each
treasures @ 0= ;

: <eaten-by-monster?> ( flag node -- new-flag ) \ NODE must be in the MONSTERS list
player @ collision? or ;

: eaten-by-monster? ( -- flag )
false
monsters @ ['] <eaten-by-monster?> each ;

: guide-monster ( node -- ) \ sets the .DX .DY offsets for the monster
player @ seek ;

: erase-movers ( -- ) \ the monsters and the player can move
monsters @ ['] erase-object each
player @ erase-object
;

: move-monsters ( -- )
monsters @ ['] guide-monster each
monsters @ ['] move-object each \ monsters can run into each other and occupy the same space
;

: move-player ( char|false -- )
guide-player
player @ move-object
;

: draw-all ( -- ) \ treasures, monsters and the player
treasures @ ['] draw-object each \ treasures first so a monster can overwrite it
monsters @ ['] draw-object each
player @ draw-object
;

\ DRAW-ALL redraws the treasures in case a monster over-wrote it previously.
\ The treasures are drawn first, so if a monster is there the monster will over-write it in the display.

: <main> ( char|false -- str|false )
cycles @ severe 4 / >= if \ the monsters are becoming increasingly aggressive
wide-eyes player @ .kind ! then
erase-movers \ -- char|false
move-monsters \ -- char|false
move-player \ --
draw-all \ --
taken-all-treasure? if c" WIN! :-D " exit then
eaten-by-monster? if c" LOSE :-( " exit then
false ;

\ Monsters can run into other monsters or the treasure and occupy the same space.
\ If a monster is on top of a treasure, the monster is displayed (because monsters are drawn after treasures).
\ Neither monsters nor the player can occupy the same space as a wall.

: main ( -- )
init-game
begin key? until \ don't begin game until player presses a key
['] <main> play-game
treasures @ ['] kill-object each
monsters @ ['] kill-object each
player @ kill-object ;

[hughag...@gmail.com]

On Sunday, April 2, 2017 at 9:07:54 PM UTC-7, Ron Aaron wrote:
> On 03/04/2017 6:38, Julian Fondren wrote:
> ...
> > Of your names...
> >
> > mptyspace
> > plyrsymbl
> > mnsterpos
> > scrnarry
> >
> > I worry that if I use gentle tone that you'll conclude that they're
> > not so bad, so let's just say that you deserve the death penalty for
> > these names. I won't hear any libertarian talk about how you're
> > practicing your naming in the privacy of your own home and aren't
> > harming anyone. You will be made an example of.
>
> Julian: Darren already mentioned he has trouble discerning humor from
> serious discussion...

Both Julien Fondren and Ron Aaron have made death threats against me in the past, which I didn't find humorous.

ANS-Forth is a cult. Elizabeth Rather is totally focused on loyalty. If a person is loyal --- and Julien Fondren is extremely loyal --- then she is totally okay with grossly offensive behavior, including death threats.

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
> I don't know what this means, so I will have to come back to this
> later. Certainly I could download a newer version. I didn't realize I
> had never installed gforth on this machine.

Typically you'd use a package installer which deals with all that path
stuff for you.

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
> No, I'm not making fun of you. I'm using Windows. gForth will run
> under Windows and I believe I've done that, but it must have been on
> my last laptop.

I think this handles everything:

https://www.complang.tuwien.ac.at/forth/gforth/gforth-0.7.0.exe

[hughag...@gmail.com]

In VFX, SwiftForth and Gforth FIND behaves differently, so any program that assumes one of these behaviors will not run on the other systems, despite the fact that all of them are ANS-Forth compliant.

The problem is that ANS-Forth is ambiguous.

If Darin wants compatibility between ANS-Forth systems, then he needs to start with the disambiguifiers:
--------------------------------------------------------------------------

\ ******
\ ****** Our disambiguifiers --- these allow FIND to work consistently on all ANS-Forth systems.
\ ******

\ The disambiguifiers should not work in interpretation mode. Because of this, I previously had them abort on STATE @ 0=.
\ Anton Ertl complained that this prevents them from being used inside of [ ] which sometimes makes sense.
\ So, now I just have them give a warning, rather than abort, although this isn't strictly ANS-Forth compliant.
\ Some still abort though --- if they access the return-stack, they really can't be used in interpretive mode.

: +loop state @ 0= if cr ." WARNING: *** no interpretation semantics for: +LOOP ***" cr then postpone +loop ; immediate
: ." state @ 0= if cr ." WARNING: *** no interpretation semantics for: .quote ***" cr then postpone ." ; immediate
: ; state @ 0= if cr ." WARNING: *** no interpretation semantics for: ; ***" cr then postpone ; ; immediate
: >r state @ 0= abort" *** no interpretation semantics for: >R ***" postpone >r ; immediate
: abort" state @ 0= if cr ." WARNING: *** no interpretation semantics for: ABORTquote ***" cr then postpone abort" ; immediate
: begin state @ 0= if cr ." WARNING: *** no interpretation semantics for: BEGIN ***" cr then postpone begin ; immediate
: do state @ 0= abort" *** no interpretation semantics for: DO ***" postpone do ; immediate
: does> state @ 0= if cr ." WARNING: *** no interpretation semantics for: DOES> ***" cr then postpone does> ; immediate
: else state @ 0= if cr ." WARNING: *** no interpretation semantics for: ELSE ***" cr then postpone else ; immediate
: exit state @ 0= abort" *** no interpretation semantics for: EXIT ***" postpone exit ; immediate
: I state @ 0= abort" *** no interpretation semantics for: I ***" postpone I ; immediate
: if state @ 0= if cr ." WARNING: *** no interpretation semantics for: IF ***" cr then postpone if ; immediate
: J state @ 0= abort" *** no interpretation semantics for: J ***" postpone J ; immediate
: leave state @ 0= abort" *** no interpretation semantics for: LEAVE ***" postpone leave ; immediate
: literal state @ 0= if cr ." WARNING: *** no interpretation semantics for: LITERAL ***" cr then postpone literal ; immediate
: loop state @ 0= abort" *** no interpretation semantics for: LOOP ***" postpone loop ; immediate
: postpone state @ 0= if cr ." WARNING: *** no interpretation semantics for: POSTPONE ***" cr then postpone postpone ; immediate
: r> state @ 0= abort" *** no interpretation semantics for: R> ***" postpone r> ; immediate
: r@ state @ 0= abort" *** no interpretation semantics for: R@ ***" postpone r@ ; immediate
: recurse state @ 0= if cr ." WARNING: *** no interpretation semantics for: RECURSE ***" cr then postpone recurse ; immediate
: repeat state @ 0= if cr ." WARNING: *** no interpretation semantics for: REPEAT ***" cr then postpone repeat ; immediate
: s" state @ 0= if cr ." WARNING: *** no interpretation semantics for: Squote ***" cr then postpone s" ; immediate
: then state @ 0= if cr ." WARNING: *** no interpretation semantics for: THEN ***" cr then postpone then ; immediate
: unloop state @ 0= abort" *** no interpretation semantics for: UNLOOP ***" postpone unloop ; immediate
: until state @ 0= if cr ." WARNING: *** no interpretation semantics for: UNTIL ***" cr then postpone until ; immediate
: while state @ 0= if cr ." WARNING: *** no interpretation semantics for: WHILE ***" cr then postpone while ; immediate
: [ state @ 0= abort" *** no interpretation semantics for: [ ***" postpone [ ; immediate
: ['] state @ 0= if cr ." WARNING: *** no interpretation semantics for: ['] ***" cr then postpone ['] ; immediate
: [char] state @ 0= if cr ." WARNING: *** no interpretation semantics for: [CHAR] ***" cr then postpone [char] ; immediate
: 2>r state @ 0= abort" *** no interpretation semantics for: 2>R ***" postpone 2>r ; immediate
: 2r> state @ 0= abort" *** no interpretation semantics for: 2R> ***" postpone 2r> ; immediate
: 2r@ state @ 0= abort" *** no interpretation semantics for: 2R@ ***" postpone 2r@ ; immediate
: ?do state @ 0= abort" *** no interpretation semantics for: ?DO ***" postpone ?do ; immediate
: again state @ 0= if cr ." WARNING: *** no interpretation semantics for: AGAIN ***" cr then postpone again ; immediate
: c" state @ 0= if cr ." WARNING: *** no interpretation semantics for: Cquote ***" cr then postpone c" ; immediate
: case state @ 0= if cr ." WARNING: *** no interpretation semantics for: CASE ***" cr then postpone case ; immediate
: compile, state @ 0= if cr ." WARNING: *** no interpretation semantics for: COMPILE, ***" cr then postpone compile, ; immediate
: endcase state @ 0= if cr ." WARNING: *** no interpretation semantics for: ENDCASE ***" cr then postpone endcase ; immediate
: endof state @ 0= if cr ." WARNING: *** no interpretation semantics for: ENDOF ***" cr then postpone endof ; immediate
: of state @ 0= if cr ." WARNING: *** no interpretation semantics for: OF ***" cr then postpone of ; immediate
VFX? [if]
: [compile] state @ 0= if cr ." WARNING: *** no interpretation semantics for: [COMPILE] ***" cr then postpone [compile] ; immediate
[then]
: 2literal state @ 0= if cr ." WARNING: *** no interpretation semantics for: 2LITERAL ***" cr then postpone 2literal ; immediate
: abort" state @ 0= if cr ." WARNING: *** no interpretation semantics for: ABORTquote ***" cr then postpone abort" ; immediate
: fliteral state @ 0= if cr ." WARNING: *** no interpretation semantics for: FLITERAL ***" cr then postpone fliteral ; immediate
: (local) state @ 0= if cr ." WARNING: *** no interpretation semantics for: (LOCAL) ***" cr then postpone (local) ; immediate
: locals| state @ 0= if cr ." WARNING: *** no interpretation semantics for: LOCALS| ***" cr then postpone locals| ; immediate
: ;code state @ 0= if cr ." WARNING: *** no interpretation semantics for: ;CODE ***" cr then postpone ;code ; immediate
: ahead state @ 0= if cr ." WARNING: *** no interpretation semantics for: AHEAD ***" cr then postpone ahead ; immediate
: cs-pick state @ 0= if cr ." WARNING: *** no interpretation semantics for: CS-PICK ***" cr then postpone cs-pick ; immediate
: cs-roll state @ 0= if cr ." WARNING: *** no interpretation semantics for: CS-ROLL ***" cr then postpone cs-roll ; immediate
: sliteral state @ 0= if cr ." WARNING: *** no interpretation semantics for: SLITERAL ***" cr then postpone sliteral ; immediate

\ All of the above words are provided for working around the bug in ANS-Forth in which they either
\ lack an xt value (for example: ; in Gforth) or they have an xt value that aborts when executed (for example: IF in VFX).
\ Note that S" and C" are both state-smart in VFX, but this is in violation to ANS-Forth that says they have no interpretation semantics.
\ I don't allow them to work in interpretation mode --- this doesn't matter anyway, because I redefine them later in the novice-package.
\ All of the above were listed in the ANS-Forth manual: "Interpretation semantics for this word are undefined." According to section 4.1.2
\ of the ANS-Forth document: "attempting to obtain the execution token, (e.g., with 6.1.0070 ', 6.1.1550 FIND, etc.) of a definition with
\ undefined interpretation semantics [is an ambiguous condition]."

\ SwiftForth doesn't have [COMPILE] but VFX does --- so [COMPILE] is only disambiguified for VFX.
\ SwiftForth isn't fully ANS-Forth compliant because it doesn't have [COMPILE] --- other ANS-Forth systems presumably do have [COMPILE] though.
\ Nobody really uses [COMPILE] so it is not important (I don't know why [COMPILE] is in ANS-Forth, as we have POSTPONE).

VFX? [if]
: to postpone to ; immediate
[then]

\ The ANS-Forth document (6.2.2295) states: "An ambiguous condition exists if either POSTPONE or [COMPILE] is applied to TO."
\ Disambiguifying TO does work under VFX though, so it is provided above. It may work under other ANS-Forth compilers too, although it is not ANS-Forth compliant.

[rickman]

This is a bit odd. I downloaded this copy and it matches a copy I
already have on my drive from 2009. I have a third copy from the same
date in 2009, but a few minutes later and 1 MB smaller named,
gforth-0.7.0-20081226.exe. This was the version I tried to install.
Not sure what is different about this one, but I will try the other,
just not tonight.

Thanks for the link.

--

Rick C

[rickman]

On 4/7/2017 10:22 PM, David Schultz wrote:
> On 04/07/2017 09:04 PM, rickman wrote:
>> Do you mean the MSP432? The MSP430 is not an ARM, it's a totally
>> separate 16 bit processor by TI. Some say the assembly language is akin
>> to the PDP/LSI-11.
>>
> No. MSP430FR5969 to be precise. The ARM target is the MK66FX1M0 in the
> Teensy 3.6.

I think I understand now. You are saying you wrote a Forth for the
MSP430 and you then ported it to an ARM. Got it.

--

Rick C

[Anton Ertl]

Paul Rubin <no.e...@nospam.invalid> writes:
>I think this handles everything:
>
>https://www.complang.tuwien.ac.at/forth/gforth/gforth-0.7.0.exe

AFAIK this does not work on Windows 10, so on that you can use the
current snapshot:

https://www.complang.tuwien.ac.at/forth/gforth/Snapshots/current/gforth64.exe
https://www.complang.tuwien.ac.at/forth/gforth/Snapshots/current/gforth.exe

- 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/

[Albert van der Horst]

In article <GWSFA.395181$FF4.2...@fx27.am4>,
Darin Murpy <murphy...@gmail.com> wrote:
<SNIP>

>
>Thanks for posting your views. Would you happen to have a list of "Truly

>standard Forths", because I've checked out gForth, swift Forth, eforth,

>CameForth, 4e4th, Win32Forth and none of them are "Truly standard

>Forths". Some are mostly complaint, but none are 100%, which is how I
>under "Truly" to mean. Thanks again.

I'm sure that all authors of those Forths will be grateful for
any reports about violations of Forth 94. most likely they will
react with updates or work arounds.

Also I'm sure that users of those Forths are grateful for remarks
where you were bitten by documented deviations from Forth 94.

>
>Take care now,
>
>Darin Murphy
>

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

[Rod Pemberton]

On Fri, 7 Apr 2017 21:21:10 -0700 (PDT)
hughag...@gmail.com wrote:

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

Couldn't you define a single Forth word for much of that middle portion
instead of retyping or cut-n-pasting it over and over? Ditto for the
abort" check and string emit.

: +loop HUGH_CHECK if ." +LOOP ***" cr then postpone +loop ; immediate

Obviously, you'd need a DUP on the STATE check for the IF that follows.

> : >r state @ 0= abort" *** no
> interpretation semantics for: >R ***" postpone
> >r ; immediate

Don't the redefined words using abort" need an IF after STATE @ 0= ?
If not, why are you checking STATE at all? Doesn't that leave an
extraneous value on the stack? Is it intended to be an error code?
Why? ... I.e., the string emit tells you it failed the STATE check.

> : abort"

Shouldn't you check and redefine abort" first, prior to using it in >r ?
Or, perhaps, last, after everything else is redefined? ... Either way,
I'd suspect that redefining abort" part of the way through the list
isn't correct.


Rod Pemberton

--
All it takes for humanity to conquer the world's toughest problems
is to hope, to believe, to share, and to do, in cooperation.

[Julian Fondren]

On Saturday, April 8, 2017 at 2:27:08 AM UTC-5, Rod Pemberton wrote:
> On Fri, 7 Apr 2017 21:21:10 -0700 (PDT)
> hughag...@gmail.com wrote:
>
> > : +loop state @ 0= if cr ." WARNING: *** no
> > interpretation semantics for: +LOOP ***" cr then postpone
> > +loop ; immediate
>
> Couldn't you define a single Forth word for much of that middle portion
> instead of retyping or cut-n-pasting it over and over? Ditto for the
> abort" check and string emit.

Strictly speaking, if you want to be rude, then the answer is... yes
of course. You could for example have

: bad-word >IN @ >R : ... build string ... EVALUATE ;

bad-word >R bad-word R> bad-word R@
...
: abort" .\" this one has \" in it so I will just special-case it" ;

Or more code to avoid repeating BAD-WORD . And of course, if you can
remember *why* anyone would avoid the use of EVALUATE, instead of just
internalizing "people complain when I use this word. I must ensure
nobody can ever find fault in me ever, so I shall avoid it", then you
can see that EVALUATE is completely fine here.

So why does Hugh write code like this? I can only assume that it is
because Hugh is not a Forth advocate, but an advocate of post-Forth.
He has left Forth behind. Meaning: he is moving in a direction. A
direction his body must be facing. And probably his eyes are on the
side of his body aligned with the forefront of movement in that
direction. And if so, his eyes can see, on the horizon: that in order
to reach post-Forth, many things will have to be deleted. So Hugh is
perhaps already writing his 64-bit all-words-tickable code as if such
features of Forth do not exist.

> > : >r state @ 0= abort" *** no
> > interpretation semantics for: >R ***" postpone
> > >r ; immediate
>
> Don't the redefined words using abort" need an IF after STATE @ 0= ?

ABORT" hi" is similar to IF ." hi" ABORT THEN

> Shouldn't you check and redefine abort" first, prior to using it in >r ?

The only point of this code is to make these words tickable. None of
the words depend on any of the words being tickable so the order of
definition doesn't matter.

[Mark Wills]

Just check out Elizabeth's books. They are based on modern Forth.

[m...@iae.nl]

On Saturday, April 8, 2017 at 3:31:09 AM UTC+2, Darin Murphy wrote:

As the transcriber of Starting Forth,
please allow me to explain some aspects that
have not been properly addressed yet. I also
want to make some additional comments.

It seems that 99% of the problems discussed
in this thread can be solved by properly reading
a section in the on-line version's Acknowledgements.
I'll reproduce and annotate it here:

"Starting Forth, First Edition is from 1981. These
web pages were designed in 2003, when it became
apparent that SF would never be re-issued by the
copyright holder. A small supply of about 500 books
was all that was left.

When you can get hold of the original, do so."

My 2003 transcription (home.iae.nl/users/mhx/sf.html)
was illegal, or at least unsanctioned.
I found it unacceptable that this refreshingly
unconventional textbook, which had instantly converted
me to a Forth addict when I was still at university,
would become unavailable to next generations.

It took me about a year to transcribe the text and
adjust the code. I did not have access to the original
artwork. Leo's original drawings were back-added by
Forth Inc. when they eventually approved my
transcription and setup their own SF pages at
https://www.forth.com/starting-forth/ . We reached
an agreement that is described in the
"Copyright Notice" you find in the Acknowledgement
section of the transcript.

The two page sets contain the same text, but
Marlin Ouverson has adjusted the look-and-feel of the
Forth Inc. rendering by properly sabotaging the HTML
standards :-)

"In this transcript Forth code has been ANSified.
The samples should run on, at least, iForth and
SwiftForth. Where necessary, statements that were
valid in 1981 have been exchanged with statements
more appropriate for 2003 (when this tribute was written)."

I guess this is the measure that causes the present
confusion.
*None of the code in the original SF (OSF) is ANS,
because ANS Forth did not exist when OSF was
written.*

There is no way a modern Forth can run OSF examples
unmodified, unless one first writes an emulator for
OSF's Forth dialect (16-bit threaded code) in ANS
Forth--a 64-bit optimizing compiler, most probably.

Such an emulator would not teach the reader modern
Forth. It'd only allow to recreate the experience
of the original readers of OSF. This would be about
as useful as writing a MIX emulator to try out the
algorithms in Knuth's TAOCP.

"Starting Forth is full of very difficult to reproduce
graphics. These enormously enhance the text's mnemonic
value, and are invaluable for a first-time Forth user.
I have therefore added "substitute" graphic elements,
roughly at the same spot where they are in the original.
The original graphics are, of course, much better."

Mrs. Rather does not like, and consistently never has
liked, Leo's pictures.
Although I respect her opinion, it is well-accepted
that pictures work (https://www.mindtools.com/memory.html).

With regards to silliness, e.g. "LaTeX: A Document
Preparation System", uses pictures in a very serious
text aimed at very serious people.

"In this transcript I have assumed a 32-bit,
byte-addressing Forth, with 8-bit characters.
The address returned by WORD is assumed to be HERE.
This allows the common trick of ALLOTing length of
str CHARS after using WORD in order to compile
string str to memory. Multitasking issues are
ignored (e.g. no >TYPE, just TYPE). Division is
symmetric, not floored, and two's complement is
assumed throughout. Most Forths should not have
problems with this. Chapter 7 exploits extended
uses of number conversion. Some Forths are broken
in this respect, but iForth and SwiftForth do support
these neat features."

At the time the ANS standard was developed,
there were people that for various strategic
reasons loved to point out why conventional Forth
phrases would NOT work on OrangeCarrotHead Forth as
released in 1947 for the big-endian 1's complement
55-bit IBM 321 mainframe. I did not want any of such
if's and but's in the transcribed SF, and opted to show
Forth code that should run on a "reasonable" Forth.
I made sure that at least two existing Forths could
run all the code of the new SF, and added
warnings for code that was far left-field.

It is great that no contributor here remembers
anymore that in pre-ANS times it was *impossible* to
take a snippet of published Forth and run it on one's
own system. CFA, LFA, ', ['], signed division, 2+ for
addressing, 1-based PICK, segmented 16-bit Forth,
floating-point, blocks, non-standard words with
standard names (OR, NOT) ...

Then about that OCTAL thing in Chapter 8:

"Your Forth system already has a number of
variables defined; one is called BASE. BASE
contains the number base that you're currently
working in. In fact, the definition of HEX and
DECIMAL (and OCTAL, if your system has it) are simply
: DECIMAL 10 BASE ! ;
: HEX 16 BASE ! ;
: OCTAL 8 BASE ! ;

What is there to be confused about? Doesn't gForth
have BASE ?

-marcel

[Alex]

On 4/8/2017 02:20, Darin Murpy wrote:
> Mrs. Conklin/Rather

I'm curious. Why are you addressing Elizabeth this way? I know where the
surnames come from, but her sig is Elizabeth Rather, and you give
everyone else (Rick, Albert etc) the first name treatment.

--
Alex

[Anton Ertl]

m...@iae.nl writes:
>My 2003 transcription (home.iae.nl/users/mhx/sf.html)
>was illegal, or at least unsanctioned.
>I found it unacceptable that this refreshingly
>unconventional textbook, which had instantly converted
>me to a Forth addict when I was still at university,
>would become unavailable to next generations.

I applaud your effort and courage in bringing back this book, and
Forth, Inc.'s wisdom to pick it up rather than crushing the effort.

[My own introduction was different: I first bought and read Alan
Winfield's "The Complete Forth", which did not inspire me, and then
Ronald Zech's "Die Programmiersprache Forth", which, despite being
horribly organized, inspired me by explaining the internals in
addition to the more application-oriented stuff. I did not read
"Starting Forth" until much later.]

>"In this transcript Forth code has been ANSified.
> The samples should run on, at least, iForth and
> SwiftForth. Where necessary, statements that were
> valid in 1981 have been exchanged with statements
> more appropriate for 2003 (when this tribute was written)."

Maybe you could exchange the few places where the code is specific to
iForth/SwiftForth with standard code. None of the things Darin Murphy
mentioned seems to be essential.

Also, it might help if it was clearer what is input and what is
output. Maybe it is just my browser settings that make it hard to see
the difference, but Darin Murphy apparently does not see the
difference, either.

>"In this transcript I have assumed a 32-bit,
> byte-addressing Forth, with 8-bit characters.
> The address returned by WORD is assumed to be HERE.
> This allows the common trick of ALLOTing length of
> str CHARS after using WORD in order to compile
> string str to memory. Multitasking issues are
> ignored (e.g. no >TYPE, just TYPE). Division is
> symmetric, not floored, and two's complement is
> assumed throughout. Most Forths should not have
> problems with this. Chapter 7 exploits extended
> uses of number conversion. Some Forths are broken
> in this respect, but iForth and SwiftForth do support
> these neat features."

Unfortunately, neither iForth nor SwiftForth run on the Raspberry Pi.

Concerning the other things:

32-bit: 32-bit iForth is no longer available. Forth is good at
cell-size independence, why not make use of that? Yes, ok, it's cool
if you can show concrete results, and they actually agree with those
on the used system, but then you can do without knowing what HERE
produces on the used system ...

Byte-addressed with 8-bit characters: Yes, few people even use
cell-addressed machines, and close to 0 start learning Forth on such a
machine.

WORD: That property of WORD is pretty widespread, so it is probably
ok. However, given PARSE (1994) and PARSE-NAME (2012), one might
exchange the WORD usage in a 2017 update.

Division: Switching / MOD etc. from symmetric to floored in Gforth has
resulted in few, if any complaints, so it seems to me that people
don't use these words in a way where that difference makes a
difference. So I don't think it's appropriate to put examples in
Starting Forth where it makes a difference. If you want to have
examples where it makes a difference, why not use SM/REM (or FM/MOD)?

Input number conversion: If these features are so neat, why has nobody
proposed to standardize them? Looking into the future, if we get
recognizers accepted, then we can show the neatness of Forth by adding
these features to a standard Forth as recognizers (just like the book
shows how to output numbers in such formats by writing appropriate
Forth code. If we don't get them accepted, nor proposals for
SwiftForth-compatible input number conversion, then the feature is
apparently not neat enough.

In any case, there is the issue of the output number conversion that
produces $200.00, and the Forth-2012 input number conversion
interprets it as double-cell hex number, which is not what was
intended; you may want to do something about that.

>It is great that no contributor here remembers
>anymore that in pre-ANS times it was *impossible* to
>take a snippet of published Forth and run it on one's
>own system.

I remember very well that I took the code from [belinfante87], typed
it into my fig-Forth-based system, and ran it there. I may have had
to adjust a few things, but far less than on my own code once it has
been mhx-ed.

@Article{belinfante87,
author = "Johan G.F. Belinfante",
title = "S/K/ID: Combinators in Forth",
journal = jfar,
year = "1987",
volume = "4",
number = "4",
pages = "555--580"

}

>CFA, LFA, ', ['], signed division, 2+ for
>addressing, 1-based PICK, segmented 16-bit Forth,
>floating-point, blocks, non-standard words with
>standard names (OR, NOT) ...

What about signed division? 2+ for addressing was universal as long
as 16-bit systems on byte-addressed machines were standard (i.e.,
before Forth-94). 1-based PICK, and NOT worked nicely until Forth-83
broke compatibility. OR is only a problem with
machineForth/colorForth.

>Then about that OCTAL thing in Chapter 8:
>
>"Your Forth system already has a number of
> variables defined; one is called BASE. BASE
> contains the number base that you're currently
> working in. In fact, the definition of HEX and
> DECIMAL (and OCTAL, if your system has it) are simply
>: DECIMAL 10 BASE ! ;
>: HEX 16 BASE ! ;
>: OCTAL 8 BASE ! ;
>
>What is there to be confused about? Doesn't gForth
>have BASE ?

Chapter 7 first mentions OCTAL "(available on some systems)", and only
later gives the definition of OCTAL. Also, earlier you mentioned that
you make some assumptions to avoid always to have to write "ifs". Why
not make the assumption that OCTAL is not available and define it just
like you define BINARY; or don't mention it at all?

[Anton Ertl]

Darin Murpy <murphy...@gmail.com> writes:
>I'm sorry Mrs. Conklin/Rather, but how can Swiftforth, and Gforth be
>standard and yet not work with "Starting Forth" which is also supposed
>to be written in Standard Forth? This is rather confusing. If they are
>all "Truly" standard Forth, shouldn't they all be 100% compatible?

Yes. However, as Marcel Hendrix explained the updated version of
Starting Forth does not use standard Forth, but an enhanced version
that worked on iForth and SwiftForth when he updated it.

>[How can something] not be compatible with a
>book that has been setting the standard for the last 36 years?

It's obvious that Starting Forth has not been setting the standard for
the last 36 years. Neither the 1981 version (subsequent standards
were incompatible with it) nor the 2003 update by Marcel Hendrix (the
non-standard features he used were not picked up by additional systems
and were not proposed for standardization).

[Anton Ertl]

"Elizabeth D. Rather" <era...@forth.com> writes:
>The important reason for not using Starting Forth as an introduction to
>Forth is that it portrays a very primitive system that will be
>unattractive to programmers interested in serious programming, an
>impression that is enhanced by its cute cartoons.

And yet Starting Forth has attracted many programmers to Forth over
the years. Maybe they were not interested in (what you consider)
serious programming from the start, but interests change. My guess is
that those people interested in (what you consider) serious
programming will look at the TIOBE index and pick the language at the
top spot (Java at the moment) or the one with the biggest increase
since last year (Go at the moment).

> For example, using
>blocks for source and data was an attractive option when many Forths ran
>standalone without a host OS, for example, but is a turnoff to
>programmers who prefer their own programming editors.

Updating it to show the use of files is possible, but unfortunately
suffers from the problem of being very setup-specific.

>And ITC is simple
>to implement, but slower than the optimizing Forths that can be found in
>increasing numbers (particularly when the ITC Forth is implemented in
>C)

Given that the 2003 edition was written to work with iForth and
SwiftForth, I am sure that all references to ITC are gone.

[Darin Murpy]

m...@iae.nl wrote:

> It seems that 99% of the problems discussed
> in this thread can be solved by properly reading
> a section in the on-line version's Acknowledgements.
> I'll reproduce and annotate it here:

Wow, thanks for coming on here and clarifying the reason "Starting
Forth" is not compatible anymore with modern forth! I am very grateful
that you took the time to explain things so well. I've been to your
website and even downloaded the glgames folder to study it after I
become more efficient with Forth and Assembly. I am also impressd that
you spent so much time back in 2002-2003 transcribing and adjusting SF
to bring it up to, at the time, compatibility. If more people in the
Forth world had your respect for that tome and the drive, than it would
have never have gotten to such incompatibility. As it stands it is only
a reminder of the glory of what was and a glimmer of what could be.
Anyway for the most part SF has worked with Gforth, so I'm still using
it till I complete the book which should be in the next week or two.

>
> Then about that OCTAL thing in Chapter 8:
>
> "Your Forth system already has a number of
> variables defined; one is called BASE. BASE
> contains the number base that you're currently
> working in. In fact, the definition of HEX and
> DECIMAL (and OCTAL, if your system has it) are simply
> : DECIMAL 10 BASE ! ;
> : HEX 16 BASE ! ;
> : OCTAL 8 BASE ! ;
>
> What is there to be confused about? Doesn't gForth
> have BASE ?
>
> -marcel

Yes, that part was my error. When I brought up this post, I some how
remembered incorrectly about OCTAL, but the other things I mentioned
were accuracte. It doesn't matter anyway. I've been able to
successfully move up to Chapter 8 and was able to complete the exercises
for the most part. Besides there really isn't anything I can do at this
point since Forth, Inc., is no longer supporting SF, which they should
remove from their site since it's no longer relavent save for a few
experienced Forthers to look back over from time to time and remember
how it helped them become Forth programmers. Again Marcel, thank you
for all of the work you have done to try and bring SF into the
Twenty First Century and the awesome website too! Take care now,

Darin Murphy

[Darin Murpy]

Anton Ertl wrote:

> And yet Starting Forth has attracted many programmers to Forth over
> the years. Maybe they were not interested in (what you consider)
> serious programming from the start, but interests change. My guess is
> that those people interested in (what you consider) serious
> programming will look at the TIOBE index and pick the language at the
> top spot (Java at the moment) or the one with the biggest increase
> since last year (Go at the moment).

I agree with Anton, while I was in the IT Industry (20+ years), I delt
with a lot of programmers (mainframe thru webdeveloping) and most of the
were looking for the money languages (C++, Visual Basic, Fox, Java,
Javascript, Perl, etc.,). Forth is not a money language currently, and
last time I checked as of March 2017 Forth is below the 50 mark, so
most young would be programmers will never see it.

>> For example, using
>>blocks for source and data was an attractive option when many Forths ran
>>standalone without a host OS, for example, but is a turnoff to
>>programmers who prefer their own programming editors.
>
> Updating it to show the use of files is possible, but unfortunately
> suffers from the problem of being very setup-specific.
>

Actually for my own purposes eventually, I will prefer a stand alone
ForthOS because I'm going to moving away from mainstream OSs, save for
Raspien which I can run emulators on for games. I might go back to the
original Starting Forth that ran Fig if I can find one that will run in
dosbox, that way I can avoid errors and look at Forth when it was still
a self supporting language and didn't have all those complexities that
make the mess we have today in our software industry. LOL!!!

>>And ITC is simple
>>to implement, but slower than the optimizing Forths that can be found in
>>increasing numbers (particularly when the ITC Forth is implemented in
>>C)
>
> Given that the 2003 edition was written to work with iForth and
> SwiftForth, I am sure that all references to ITC are gone.
>
> - anton

Thanks Anton for your opinion, suggestions and ideas. Take care now,

Darin Murphy