Looking for a good presentation of the ANS Forth 94 dictionary, not the document
LoopyByteloose
Posts: 12,537
Okay, now I am interested in access to good references for Forth. In particular, I seek a good way to assimilate the whole ANS Forth dictionary.
Over the years, this programming language has managed to intrigue me and then frustrated me as it is obvious that the dictionary is rather huge and for those of us that are not a genius that is a full 3 or more standard deviations from the norm it does not quite seem intuitive.
I have no trouble at all with stack manipulation and actually still use RPN for all my serious number crunching. I even have an HP50g calculator. But when the 'words' begin to define places and procedures that are rather full of jargon, I get lost.
The ANS Forth presentation may be complete, but the groupings are not easy to associate with productive applications. I am reading a rather odd variety of documentations and tutorials to try to penetrate this barrier. And I have revisited the 'classics' by Leo Brodie. But I find that words such as #> tend to confound me.
I just wish that someone might write "ANS Forth 94 words explained, for dummies".
Meanwhile, I may download the whole list to a spreadsheet and try to catagorize them myself.
Over the years, this programming language has managed to intrigue me and then frustrated me as it is obvious that the dictionary is rather huge and for those of us that are not a genius that is a full 3 or more standard deviations from the norm it does not quite seem intuitive.
I have no trouble at all with stack manipulation and actually still use RPN for all my serious number crunching. I even have an HP50g calculator. But when the 'words' begin to define places and procedures that are rather full of jargon, I get lost.
The ANS Forth presentation may be complete, but the groupings are not easy to associate with productive applications. I am reading a rather odd variety of documentations and tutorials to try to penetrate this barrier. And I have revisited the 'classics' by Leo Brodie. But I find that words such as #> tend to confound me.
I just wish that someone might write "ANS Forth 94 words explained, for dummies".
Meanwhile, I may download the whole list to a spreadsheet and try to catagorize them myself.
Comments
Gforth is out there as a kitchen sink Forth implementation. It runs well on Linux. They claim ANS compliance and I think have a bunch of words beyond ANS. there is a lot of documentation for it and when you start Googling, you end up with a manual, a tutorial and an HTML word list. Like I said it has bunches and bunches of words.
All the word definitions in PropForth, Tachyon and Gforth make my head spin. For PropForth, I have the .f files printed out and annotated. I made an index (see PropForth wiki) so you can tell in which .f file the word is defined. For Tachyon, I have a spreadsheet I'm trying to build and maintain (slow progress). For Gforth, I have the manual and word list open in a browser whenever I'm using it. My memory isn't what it used to be, so I usually have some references near by.
I'm finding this memory thing to spread into other languages, too. My head has become a tower of Babel as far as programming languages and sadly, I code most everything with reference tools nearby. Functions, operators, libraries; many so close but not quite!!
By whole list do you mean? http://forth.sourceforge.net/std/dpans/
If you have question about particular words, the best way might be to ask for examples.
For example #> is (usually) only used in conjunction with its mates <# #S and # to set up a formatted string as in
<# #S # # # # #>
This converts the value on the stack to the stack to three digits in the number base for printing etc.
Then you can get and address and a length on the stack, and you can use the word that takes a length and an address and print or copy or manipulate that prepared, formatted string. If 137 were on the stack, and the base were decimal, it would yield 00137. the same with number base of hex would yield 00089
I think. I seldom use this one, its too confusing. Unless somebody is paying for a profession application; then I have to dig out the dpans again. I don't recall seeing this in propforth, nobody has asked about it yet, so it may be in the "optional extensions for later if anybody asks for it" list.
Initially i tried some years ago to download a copy of "Starting Forth" by Leo Brodie, but the PDF file was rather fragmented. Today, I found out that I can't find a good PDF version, but Forth, Inc. has the original available on-line and it is quite clear. I may stay away from the ANS Forth spec for awhile and just try to get something working in PropForth.
http://www.forth.com/starting-forth/sf1/sf1.html
I am collecting quite a list of other stuff, but unsure of the quality of that, so I will not mention anything else - except to say that "Thinking Forth" by Leo Brodie is not really a beginner's text. It is more conceptual and procedural. One should start with "Starting Forth" and do some projects before getting into it.
GForth is huge, like all PC Forths. But it is handy if I just want to check out something I read.
I mentioned that out-of-print Forth books are readily available via AbeBooks.com for very reasonable to outrageous prices.
So far, I am just surfing and reading - not trying to build a library.
More reading about ANS Forth came up with comments that no one really tries to comply with the whole thing - everyone does a sub-set. So the standard is merely an idea book for portable Forth code. And portable Forth code is somewhat of a fiction as everyone tries to optimize in their own way.
In other words, Forth is and will always be a thinking man's computer language. It morphs every time it gets passed on and really used.
As long as I can identify useful fundamental elements that are equivalent to something like Parallax's PBasic, I think I have enough to get started. It is just that some presentations do not clearly explain branching and looping and bit-banging i/o.
Starting Forth is pretty good. But micro-controller bit banging needs to be found through other resources.
The world of information and tools are divided by threes.
For information - it is need to know, nice to know, and garbage.
For tools - It is must use, can use, and forget it.
BTW, porting pForth to the Propeller will be an interesting demonstration of whether Catalina C or GCC really accept C programs from beyond.
PropForth also has a document that lists all the Words for immediate reference - about 12 pages of print out. I don't know why this isn't included in the Zip file for V5.03. I picked it up some time ago with v4.60.
Here it is.
http://code.google.com/p/propforth/wiki/PFquickRef
Full ANSI may be an admirable goal, but for the new learner it is just like learning any other vocabulary. It is the highest use words that one needs to learn first. Rarely does one read a dictionary, retain everything, and learn a foreign language. But I certainly remember how to ask where the bathroom is.
For the list check mindrobot's.
Massimo
The PFQuickRef is done the right way for learning.
My $0.02 on the standard-
The "standard" words don't always make sense. In the case of propforth, for example, the "store" ! and "fetch" @ words don't makes much sense.
These words are defined as "per the cell size". In the COG, cells are long; but in HUB cells are bytes, but they are word aligned. So which it it for store and fetch?
So the answer is "none of the above".
If you want cog, you use COG! and COG@, these act on a long in cog memory.
If you want hub memory, you use C@ and C! for byte, and W@ and W! for words.
So in the case of store and fetch and propforth, these will never be implemented, for an obviously sound reason. If that means its not compliant to the standard, then its a good thing.
Also there are the words CREATE and DOES>
CREATE starts a definition, and leaves the address on the stack. Propforth's dictionary doesn't work that way, So create is not implemented.
DOES> identifies the run time behavior of a an immediate (compile time) function. We decided that this is a bad idea, we should just have compile time words at compile time, and run time words are run time. We reached this conclusion since DOES> is always the toughest word to learn how to use, and the source of a large number of mistakes. Also, one can easily have the same compile time functionality and run time functionality by using two separate words, so DOES> buys us nothing but trouble.
"Standard" just means "generic". An actual implementation on a micro controller is NOT generic, it is specific to the micro controller, just as is assembler.
As far as sorting the words into functional groups, the doc you see was done by Brian when he was learning about pf4.0. If you wish to update the list per the current release, this would be a good learning exercise, and of benefit to other folks that like to organize things the same way you do. Be aware that 5.3 is coming out soon, and there may be some differences from 5.0.3 to 5.3, just as there may have been differences from 4.0 to 5.0.3. (I think all the changes are internal to the system and not visible to the user, but I could be wrong).
I've spent most of the weekend learning Forth by writing an interpreter. I've implemented 93 out of the 133 ANSI core words. 67 of them are in the kernel and 26 in a dictionary. I'm hoping to knock out the remaining 40 in a couple of more days, but that might be optimistic.
Notice, that on the prop, if you REALLY must have @ and !, you can define them to point to COG@ and COG!; or they could point to W@ and W! on the prop. But this would only be correct half the time, since the cell size in the COG is long and cell size in the HUB is word. If its not right all the time, its not right. So its wrong. (For me, anybody else can do anything they want).
Also notice in "regular" forth implementations, C! and C@, W@ and W! explicitly define the size being addressed; while @ and ! leave you to guess. This is not a problem (as you probably know the cell size on the processor you are working on), but does give you a problem when you try to port you code to a new processor or forget or otherwise don't know the cell size. This has been a stumbling block for years. We decided that it is best to be explicit in all cases.
The "standard" is just a generic example, and we are not required to implement ANY of it. We are completely free to make any engineering decisions that allow us to do our job easier. Sometimes it helps to find what the experts learned when they had to make this decision many times before. But we are still encouraged to make our own mistakes and learn for ourselves.
I understand that Forth can be implemented anyway a person wants to. Of course, it can't be claimed to be standard Forth unless it implements all of the core words. It seems that standards-compliance and portability isn't a priority in the Forth world like it is for other languages. I tend to like the predictability of standards compliance and portability, which is why I'm implementing the ANS core words.
Currently, I'm developing my interpreter under cygwin on my PC. It's written in C, and I plan on porting it to the Prop at some point. As I said, this is more of a learning experience for me than actually producing something that is practical.
So if you use 32 bits, and byte, you have a problem. You have impliment tons of overhead to resolve this when a simple design decision would have solved it. Your choice. But, if you stick with it, you will see how the other choice would have had merits.
The people the wrote the standard told me the standard is just a guideline. That is, we DON'T need to to implement every word. The standard it so that if we DO implement a word, we know how other folks did it. That is all. In fact, they said it would be detrimental to implement them all, since some are contradictory and only present for historical reasons. The real point is we are supposed to do what we need to accomplish the task at hand, not to comply with some irrelevant tome. But your exercise is a good one, it will show you the reality of this statement (or not).
If you write it in C, it might be "like" forth, but forth is written in forth. THAT's an indication of whether its forth or simply "forth-like". But it is a good experiment. Can you post your code? (In a different thread, we are high-jacking this one).
Thanks Dave. I was NOT aware that the Section numbers were helpful. I will make a copy and print it out for reference.
On other fronts, I have PropForth V5.03 loaded into a ProtoBoard and running nicely. It is a lot of fun, but obiviously NOT ANS Forth standard.
As I have several of these Proto Boards (I bought 5 some time ago), I am going to load Tachyon Forth into another.
Of course, when you have something viable - I'd be delighted to load your ANS Forth into yet another.
What I really LIKE is that Forth does not require you to run and IDE and have to compile back and forth. There is a lot of spontaneity in how one uses it to explore and learn. Plus the Proto Boards will provide a directy VGA and keyboard interface - so it is possible to make the whole thing stand on its own.
Can't wait to see it and play with it! I figure any Forth (or Forth-like) addition to the family is welcome!!
That listing you posted is still mostly an alphabetical sort regardless of what you thought. It appears to be shorter, but not what I was hoping for. I may use it to make my own though.
PropForth is pretty good, but the leading zeros in the Decimal display without CR for consecutive stack items tends to be a bit hard to look it, and even harder to read.
ANSI standards are written by representatives from various American companies. The standards are designed by committee, so they do end up with compromises in them that can seem odd at times. Most standards contain required features that must be implemented, and optional feature which may be implemented. ANS Forth requires that a standard compliant implementation support all of the core words. The remaining words are optional.
Your definition of "forth" versus "forth-like" doesn't make sense. The ANS Forth standard has no such requirement as far as I know.
I don't really like the idea that I am making you do my work for me. I just think that one of the problems with learning Forth is that the people that really use it tend to not think very much about teaching it.
I appreciate your concern, but I am rather embrassed to say that I am not quite sure. What I was mentioning is something that is more conceptual in learning foreign language vocabulary - word groups that have an associated form of utility.
In this case, all the looping items together, all the branching items, all the bit-wise operators, all the stack manipulation items, and so on. It was just my observation that the ANS Forth document was a difficult document for a novice to penetrate, though I presume there is a lot of wisdom in what it says.
One of the things that you might be interested in is the simple fact that you could rename all the non-standard terms in PropForth and have it comply more closely with ANS Forth.
The true dilemma is that Forth is far closer to a true language than any other computer language in that everyone acquires their own vocabulary and thinks it suit them well. Computer languages tend to NOT have homonyms and synonyms and multiple terms for the same idea, but Forth might have to work with these issues at one level or another between users. Nobody has ever really standardized a spoken language.
Check out the JupiterACE from propforth versions 3.2 to 3.5. This includes the first pass at VGA + keyboard for standalone propforth terminal. HiRes VGA displays TWO COG sessions at once, COG3 on top half of screen and COG4 on bottom half of screen. This is going to be brought forward to v5.3 when its released, and will enjoy all the benefits of optimization, EEPROM file system, SD memory, and multiple external props. So it will be moving from "Wow! Cool!" to "WOW! COOL!"
Okey dokey, I'm just telling you what the authors said. In the case of forth, and micro controllers in general, there is a different meaning for "interoperability" and portability" for development kernels than for complete user systems such as video conferencing or telecom systems. The stuff from wide telecom system level is not the same at embedded device level.
Interoperability means you define the interfaces. Portability STILL means your have to rewrite the drivers for different hardware. In the case of forth, the whole development environment is a driver for different hardware, that being each target processor.
Be careful. You are not wrong, but when you apply an evaluation from the context of a video conferencing system to a micro controller development tool, you get non-answers.
I tested my Forth interpreter on various Forth programs I found on the internet. I also ran most of the code in "Starting Forth" and "A Beginner's Guide to Forth". I found that a lot of the ANS Forth programs use a few words that are not in the core set, so I had to implement a few of the core extension and other ANS Forth words. Non-ANS Forth programs are harder to port. They use words that are defined in specific Forth interpreters. This makes it really hard to port these programs.
I think my next step in learning Forth is to work with PropForth and Tachyon. I wrote a Forth program to list ANS words that aren't in the dictionary, and I'll see if I can implement those in one of the Prop Forth interpreters. Though I have a much better appreciation for the strengths of Forth, I also understand some of its weaknesses as well. The lack of local variables seems like a real problem for large programs. I also miss the ability for the compiler to do type checking and catching other syntatical errors that I find extremely useful in other compilers.
I am plugging away on PropForth and parallel learning of ANS Forth via GForth, which is a free download for Intel computers. The idea is to get a good comparison of the use on a regular computer as well as the a feel for Forth on a Propeller.
I haven't done too much with Tachyon Forth yet, even though I have it loaded into one of two Proto Boards (the other is loaded with PropForth and the two are connected back to back via standoffs, so that I can have both handy to explore).
I am very please with how easy it is to get the Propeller to output and toggle pins via RS232 port terminal. Forth makes the Propeller a Lab Rat's wonder board as one can just sit and a computer and control the world within a few minutes of learning the language.
I have started to try to do a comparative list of the ANS Forth words you provided me to the PropForth words as there are some confusing differences.
PropForth does NOT have .s and uses ST? instead.
The comparision is good for me as there is a big vocabulary to learn and you achieved much the same thing by writing your own compiler. One has to survey the words in the CORE to get started and any method that motivates the new learner is a good one.
Very cool! If you can get a version that ports smoothly from the PC to the prop (or the ATmega, or anything else) you are in a different class than I. Please share you work, I was under the impression that it was just too much work for the reasons you mentioned.
For type checking, syntax, etc; usually the system tends to just choke when anything is even the slightest bit wrong. This turns out to be the biggest plus. Since there are only a few changes to each definition before you test, its pretty clear where the error lies. Then, you can examine the definitions in detail, since you know exactly where to look. The result is the code HAS to be pretty much perfect to work, you gain a deeper understanding of what's really going on, and nobody has to waste time idiot-proofing the compiler (I for one don;t need proof that I'm an idiot). If you can get a feel for very short (but deep) design-code-test cycles, this is a very nice way to go.
I've added 30 points to what I previously considered your IQ to be and it is approaching what might be consider the boiling point of water in Fahrenheit.