AIUI, one aspect of Forth is that it's a build-your-own-language language - the core language is small and easy to learn, but you write your application by factoring it (recursively) into words. When you're done, each word you defined does something useful and directly applicable to the task of implementing your application. Each word is well-named and has a suitable interface.

Having said which, I don't know how you're supposed to handle strings or memory allocation. Perhaps someone can exhibit an Algol compiler written in Forth. (Or perhaps a task like that is a terrible fit - controlling a telescope, a spacecraft, or an internal combustion engine is the right task.)

...or file management in a fashion as we do with conventional operating environments. Case in point, just how would one implement an ISAM database in Forth? I'm sure if enough words are created it could happen, however, the database's (B-tree) index would be a very significant challenge.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

There's nothing special about any of these: strings and memory allocation are not part of C, either, and B-trees is an undergraduate-level CS exercise.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Basically, the balancing act is between learning & using heavier weight prebuilt libraries, which end up defining some of the very infrastructure you're bound to; and having to create your own complete per-project infrastructure every time, but where the language is supposed to be able to let you do that quickly. That's 100% dependent on the needs and complexity of the project.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

Disclaimer: The following is just my opinion, and should not necessarily be taken as a consensus of more than one.

There seems to be a "do it yourself" type of mentality with many Forthers, whereby they feel the need to build everything from the ground up for a given application, including the data structures and the manipulators for said structures. Hugh Aguilar has promoted the idea of building a popular pre-tested library like his Novice Package, but has been met with some resistance on comp.lang.forth. Admittedly, his obvious skills as a Forth programmer are offset by his often abrasive attitude, but it seems that many of those who are able to program large and complex applications want to use their own libraries instead of a "standard" one. Without a "standard" library for things like B-trees, beginners are forced to copy, paste and modify the necessary functionality from elsewhere, or "roll their own", making the learning curve a bit steep and frustrating.

Mike B.

Sorry, but strings are part of C. The oft-used functions from <string.h> might not, but the string themseves, surrounded by "", are definitely part of the language. To the point that, if you want to write a C program and have another type of string which is NOT null-terminated (for example, have the size as a header to the string itself), it is being a nightmare.

Without the string processing functions, the "string" construct is nothing more than a compact syntax for zero-terminated vectors of 8-bit integers representing character data. Not that it matters, anyway: the string processing functions in <string.h> (and <strings.h>) are trivial to implement.

If you're on MS-DOS, accessing the file system is just like any other language. Populate the control structure, call "int 21h", like anything else. Different Forths would expose this in different ways. If you're on CP/M, then you make calls to BDOS. The current Forth standards have word sets that provide access to files. In the 70's and 80's, the primitive Forths were the entire system, and it did not have a built in file system to leverage. It relied on the BLOCK system instead.

The dBase DBF file format (which is an ISAM and B-Tree format) is not difficult to read, nor is it's index file format. Writing is only a little more tricky because of node splits and balancing. Given a mechanism to read blocks from the files, you could be up and running reading rows from these tables in less than a day. If you can compute a block offset, you can read a dBase file.

The basic, ancient Fig-Forths did not have implicit string handling. They did have the ." word, which prints text to the closing ". It is straightforward to use that as inspiration to instead of printing the text out, it defines a string constant in memory. Forth historically uses counted strings, length followed by text. Current standard also has a String word set.

A fellow by the name of Roedy Green, who is still alive and kicking, created a very powerful DB management system in Forth ages past. It is arcane lore at this point, but I remember him from back in the BIX days (Byte Information eXchange, Byte magazines online community). He was most certainly a keen advocate for his system, and Forth was a key component to it. Today he works in Java.

The opaque stack in Forth code is what makes Forth difficult to read, as the words in the text are only the function names, and not the arguments.

In C you might see something like abc(xyz(qed())), whereas in Forth you would see qed xyz abc. Some would argue that the latter is actually easier to read. And in many ways, it is. But cognitively, you as the developer need to understand what the individual operations are doing, opaquely, to the underlying stack. In the C example the result of qed is passed to xyz, which is passed to abc. In Forth, abc(); xyz(); qed(); would look like abc xyz qed. But looking at that you don't know if it is actually abc(); xyz(); qed(); or qed(xyz(abc())) without knowing how the underlying code relies on the opaque stack.

C syntax gives you information "for free" vs the Forth syntax. This hidden information is what make Forth difficult, and it's notoriety for "write only code".

I would rather use a Lisp than a Forth, as it's almost as expressive as a Forth can be, and obviously offers some very high level facilities. But for the PRICE, in terms of machine resources, there is nothing more expressive than a Forth system. That's why it shines in small devices.

The F83 implementation on the PC is a very nice system, with some powerful constructs (notably it's meta compiler). It's a Forth written in Forth. Pygmy Forth is a very nice Forth development environment. Both are worthy of study in seeing some of the nice things that folks have done with Forth. F83 is a nice example of not just how a Forth is implemented, but some of the interesting things that can be done with a Forth. I will say, though, it is not for the faint hearted.

Just found(*) this interesting article:

My history with Forth & stack machines

(It's not entirely positive - the first part is good orientation and motivation, the second part concludes that Forth isn't the right solution for the writer.) It includes this orientating quotation:
which seems to fit well with the spirit of these following comments from this very thread:






and from here:


(*) Oops, I see scotws did mention it before, in another thread, so evidently I've already read it.

Forth has been my primary language for getting things done for years.
Even when I have to translate it into some other language to meet
some management requirement.
It has been said that well written Forth is self documenting. Doing it does
take some level of skill but it can't be done at all in other languages.
A fellow Forther had written a program for dealing with Hamming codes.
The manager sent it back to him and said that he wanted to see the
actual program and not the description of what a Hamming code is.
What better complement could a programmer get.
Forth is not a specialize application as DB is. It is just a "tool box".
It also lets a person think about how and why things work. In the programming
section, it was incorrectly stated that QuickSort is the fastest sort. It
is the fastest in place sort, by no means the fastest sort.
I cobbled together a 6502 distribution sort ( sorry, I'm not that familiar with 6502
so the code could see some optimizing ) and posted it there in the programming
section.
I doubt I'd ever even thought about sorting speed had I not seen it as a challenge
in programming in Forth.
I have a NC4000 Forth processor that runs at 4MHz. It sorts 1K 16 bit signed integers
in 19.1 ms using the code I'd written.
That is an average of about machine 75 cycles on each item to sort. QuickSort can't even come
close to that on any processor.
I'm straying from the point a little but I never would have even thought that things
could be better than the generally excepted optimums if I didn't have an environment
that I could quickly experiment in.
Forth provides that kind of environment.
It isn't really everyone's cup of tea. Many believe that to write a really large piece
of working code one needs type checking. That is if you write code that you can't easily test
code as you write it the code.
Where I work, we use commercial tools to handle large complicated task. There isn't
a single piece of this large code that doesn't have bugs. The code has been cobbled
together by so many people that depend on the language that it is written in to
to protect them from bugs that it is riddled with bugs.
Making mistakes is normal for anyone. Being in an environment that one can quickly
locate and fix bugs at the lowest levels is the only way to create large robust
applications. It is the quickest way as well.
Most languages are not well designed to allow one to do simple testing while
writing code.
Expecting to test a large piece of code with hundreds of decision points is like ensuring
failure, when tested at the top level.
Forth is one of the few languages that one can even begin to create correct code
for large applications.
Do remember, it is just a tool box. It won't make a bad coder better. Those persons
have to do that themselves.
Getting out of the big boiler plate, big compile, run debugger code, pull hair cycle is
part of what is needed to not be put off by thinking that things are too complicated
to write large application.
Dwight

Dr. Ting has released a new eForth book, and I was able to download it for free from here (not sure if this link will work for everyone):

[Edit: I deleted this link as soon as I found out that it was illegal.]

It doesn't relate directly to the 65xx family, but it is written in a captivating style which I find to be very informative and entertaining. Dr. Ting studied the MSP430 as a target, and confirmed my preference for direct threading, at least on processors having cell-wide registers and auto-increment addressing. This doesn't mean that there's nothing of interest for those looking to port eForth to other micro-processors ... his explanations cover a variety of important details, with a bit of colorful commentary mixed in.

In my opinion, it is worth the time to download it and give yourself a couple of hours to follow along with Dr. Ting and his adventures.

Mike B.

Dr Ting has implemented eForth on a number of different processors.
I've known him for a number of years.
I find his book interesting.
I have a number of the publication he produced.
His "Foot Steps in an Empty Valley" is an interesting one
on Chuck's NC4000 processor.
I have a working NC4000 system I put together with a floppy drive
and hard disk. I re-purposed a couple of XT disk controllers for it.
Dwight

Thanks for posting this. I've read his "Zen of Forth" that I've dug up on assorted sites, in generally poorly formatted, or some binary format for a word processor, but was mostly readable.

I'll have to read the rest of this later.

Yeah, the formatting is a bit amateurish in this one as well, but I still enjoyed it thoroughly. It helps me to narrate along in my head with a Chinese accent.

Mike B.