CS-101 problems and their FORTH solutions.

[barrym95838]

dwight wrote:

I might write it like this for a 6502.

Code: Select all

5 constant BuzzMax
3 constant FuzzMax

0 value FuzzCnt
0 value BuzzCnt

: FuzzBuzz
   cr
   0 !> BuzzCnt
   0 !> FuzzCnt
   101 1 do
     FuzzCnt dup 0= if
       ." Fuzz" FuzzMax !> FuzzCnt
     then
     BuzzCnt dup 0= if
       ." Buzz" BuzzMax !> BuzzCnt
     then
     or  if
       I .
     then
     -1 +!> BuzzCnt
     -1 +!> FuzzCnt
     cr
   loop ;
     

untested
Dwight

Yeah, you're clearly thinking "the 6502 way" there!

http://rosettacode.org/wiki/FizzBuzz/As ... 2_Assembly

Mike B.

[dwight]

Others have figured out !> . It could be read in typical Forth talk,
! ( store ) > ( to ). I've used Forths with all three version of TO.
I didn't like VALUE that much when I first came across it. My first
Forth was fig forth from the West Coast Computer Fair.
I implemented it on a MDS-800, from a source listing, to give a context of what date that
was.
I first assembled it just as it was and did a hex comparison to find the error.
I then reassembled it to work with the MDS-800's I/O.
Back to VALUE, over time, I've found it to be both efficient and makes to code easier
to read. I do stack manipulation when I think it needs it.
In this case, I saw no need for much. It neither improved the code or made it
easier to read.
As you may have guessed, I make a lot of mistakes while coding. I make a lot
of mistakes while writing anything.
I like Forth because it is so much easier to test and repair my mistakes.
I didn't hear the video so didn't know exactly what was wanted. I wasn't some
place to either play it out loud or to run code.
I believe the only thing I didn't do was to make it so that one could do any number of
strings with different prime numbers.
While the fellow on the video considered it a plus to design that way, I saw it as
typical programming bloat.
If one had needed that from the start, one would write a different program.
I fear that too many times coding is written for conditions that will never exist.
Such program are actually harder to maintain and are often the source of errors,
in the future, because they don't make sense in the context they were used in.
Future maintianers are not sure of the reason it was done some particular way
so try to not disturb it.
If there are requirements in the future, it is always better to rip up the code and
rewrite it ( ALWAYS ). Too much faith is put in writing reusable code. It is why
MS Windows is constantly needing patches. It is why your credit card number
is leaked.
Forth is designed to minimize discovering of your errors. Most other languages
are not like that. I only knew one programmer in my life that I believe could write
perfect code in any programming language. Most of us are not at that level.
Dwight

[dwight]

barrym95838 wrote:

Yeah, you're clearly thinking "the 6502 way" there!

http://rosettacode.org/wiki/FizzBuzz/As ... 2_Assembly

Mike B.

Using the 6502. I've grown to like dec for x and y. I have to think
a little more about the starting and terminal values ( note my initialization errors ).
It is easier to do carries from a zero test. For loops, if I don't need to count up
I count down. Even if I need the value to count up for humans to read,
I still count down. It is something like getting used to negative logic.
Dwight

[commodorejohn]

Yep, getting a freebie on the loop test with DEx/BNE ingrains itself into your way of thinking pretty hard.

[Martin_H]

nyef wrote:

From context, !> is another name for TO, and +!> would be +TO if such a word existed (add the value at the top of the stack to the following VALUE word).

I'm really not sure if I like VALUE and TO or not.

I couldn't find TO or TO+ in Forth documentation either, so I don't know what they do.

[barrym95838]

Martin_H wrote:

I couldn't find TO or TO+ in Forth documentation either, so I don't know what they do.

http://forth-standard.org/standard/core/TO

Mike B.

[dwight]

For TO

http://www.forth.org/svfig/Win32Forth/DPANS94.txt

at

13.6.1.2295

+TO is not defined but is a common extension.

5 VALUE SomeName

SomeName 6 + TO SomeName

is the same as

6 +TO SomeName

SomeName now returns 11.

Dwight

[Martin_H]

OK, I read those sections, and if I understand them it means this:

Code: Select all

0 !> BuzzCnt

is the same as this:

Code: Select all

0 BuzzCnt !

So it seems kind of pointless to me.

[dwight]

Martin_H wrote:

OK, I read those sections, and if I understand them it means this:

Code: Select all

0 !> BuzzCnt

is the same as this:

Code: Select all

0 BuzzCnt !

So it seems kind of pointless to me.

Except that to use BuzzCnt, you must do

Code: Select all

 BuzzCnt @ 

instead of just

Code: Select all

 BuzzCnt 

Also with added words like +TO,

Code: Select all

 3 +TO BuzzCnt 

instead of

Code: Select all

BuzzCnt @ 3 + BuzzCnt ! 

Although undefined in the standard, most Forths will
let you use TO with a variable. If you do this it is no longer a standard
program. ( oh my! )
I'm not much of a standards person. I believe it is kind of contrary to
the concept of Forth.
When the various standards were created, it became a "I won't vote for
your favorite word if you don't vote for mine". That is why you see the
bloat of similar but different words, doing the same thing.
I like TO and +TO. I also think VARIABLE is necessary but it is different
than VALUE.
Pinning down Forth to any standard is like shooting at a fast moving target.
ANSI Forth is a way of creating portable programs. It also gives a person
expected behavior for programs. It isn't what Forth was intended to be.
Dwight

[nyef]

Martin_H wrote:

OK, I read those sections, and if I understand them it means this:

Code: Select all

0 !> BuzzCnt

is the same as this:

Code: Select all

0 BuzzCnt !

So it seems kind of pointless to me.

BuzzCnt was created with VALUE, which means that it doesn't behave quite like a variable. Instead of BuzzCnt returning the address of some cell-wide storage, it returns the value stored in that cell, and you use TO BuzzCnt in order to update the stored value. You don't have to deal with addresses when working with VALUE, but the cost is that you are no longer able to deal with addresses when working with VALUE.

[Martin_H]

OK I get it now. I have to say the values and TO seem very unforthy.

[GARTHWILSON]

Just think of it as a constant that you can change.

dwight wrote:

Also with added words like +TO,

Code: Select all

 3 +TO BuzzCnt 

instead of

Code: Select all

BuzzCnt @ 3 + BuzzCnt ! 

If it were a normal variable, you could just do

Code: Select all

3  BuzzCnt  +!

[dwight]

Martin_H wrote:

OK I get it now. I have to say the values and TO seem very unforthy.

You might say that but if you spent some time with Chuck Moore you might
see it in a different light.
Dwight

[Dr Jefyll]

I'm not up on ANS. But this VALUE word is a win, I'd say, for two reasons.

I think readability and writeability would improve. Yes it's possible to use either CONSTANT or VARIABLE to define whatever-it-is on a case by case basis. But in some cases *either* CONSTANT or VARIABLE would be a reasonable choice. That means you need to keep track. I find (especially with a large program) that I end up continually stopping to ask myself whether word XYZ was was defined by CONSTANT or by VARIABLE. It's a speed bump doing that mental check, and of course I'm guaranteed a bug if I slip up. With words defined by VALUE the mental checking and the risk of error are eliminated.

The other reason is speed. Example:

Code: Select all

0 BuzzCnt !

... requires three passes through NEXT. But if I understand correctly...

Code: Select all

0 !> BuzzCnt

... would be just two passes through NEXT. Specifically, !> would execute at compile time, sucking in BuzzCnt from the source code. It'd then compile the !> execution token and a parameter, namely whatever passes for the pfa of BuzzCnt.

Or at least that's the way I'd code it!

-- Jeff

[GARTHWILSON]

Dr Jefyll wrote:

The other reason is speed. Example:

Code: Select all

0 BuzzCnt !

... requires three passes through NEXT.

True, but that's not a good example, because you can do

Code: Select all

    BuzzCnt OFF

in two words (and two passes through NEXT) and get the same result.