> Most of what I find written about Forth programming involves the
> basics; data stack, control structures, I/O, compilation. I'm
> interested in learning ways that complete non-programming-language-
> related applications (e.g. NOT Forth's written in Forth) have
> leveraged Forth's unique capabilities to solve problems differently
> from conventional practices.
It's a good question. It would be helpful to hear what you *have* read,
so we know where you're starting from. Have you read "Thinking Forth"
(Google for it)? Although it's somewhat dated, it does address some of
these issues.
Most of our application work nowadays is in embedded systems, which is
reflected in my comments below.
> Specifically I'd love learning about anything having to do with:
> - Using Compile Time
Aside from trivial things such as generating literals, this is a
technique that's used very rarely in my experience, but can be a
powerful weapon to keep in reserve for certain occasions.
One of my favorite good examples is the construction of a chip-select
table for a 68332. Single bits here and there in the cells of the table
control critical functions, and they make little sense examined in hex.
We made a set of words that set the appropriate bits at compile time
in ways that are absolutely obvious:
{ ---------------------------------------------------------------------
Chip select table
CHIPS is the chip select table for the NMIX-0332.
|CHIPS| is the table size in bytes.
--------------------------------------------------------------------- }
CREATE CHIPS
0 Select16 \ CS10 (A23)
Select16 \ CS9 (A22)
Select16 \ CS8 (A21)
Select16 \ CS7 (A20)
Select16 \ CS6 (A19)
0 Select16 \ CS5 (FC2)
Select16 \ CS4 (FC1)
Select16 \ CS3 (FC0)
Select16 \ CS2 (BGACK)
Select16 \ CS1 (BG)
Select16 \ CS0 (BR)
Select16 \ CSBOOT
( CSPAR0) W, ( CSPAR1) W,
Async Both Read AS 9 WS S/U 'PROM 128K \ CSBOOT
Async Both Read AS 9 WS S/U 'PROM 20000 + 128K \ CS0
Async Both R/W AS 1 WS S/U 0 128K \ CS1
Async Both R/W AS 1 WS S/U 20000 128K \ CS2
N/C \ CS3
N/C \ CS4
N/C \ CS5
N/C \ CS6
N/C \ CS7
N/C \ CS8
N/C \ CS9
N/C \ CS10
HERE CHIPS - EQU |CHIPS| IDATA
> - Usage of Wordlists (how was a program structured? how were wordlists
> used? any app-specific abstractions that used wordlists?)
We don't use wordlists very extensively in applications, but they are
absolutely vital in our systems, especially cross- and meta- compilers.
They're also critical to SwiftForth's SWOOP facility.
> - Featuring the data stack
Not sure just what you mean, here.
> - Using the interpreter to process text files, or other text
> processing applications
There's info on the in Forth Application Techniques (one of my books,
available through
www.forth.com).
> - Forth-style data structures
See Thinking Forth and Forth Application Techniques. We use this
capability extensively in applications, most of which have app-specific
data structures of some kind. Examples range from circular buffers to
named bits in an I/O register. Automatically indexing arrays are also
very useful.
> - How a complex application was structured (how did you avoid name-
> collisions? any "scripts" compiled or run from within the
> application?)
We don't actually worry a lot about name collisions in applications. A
lot of application words are only used locally, and if there's a
different one somewhere the compiler will issue a warning. Sometimes we
just examine the other version, conclude there's no practical conflict,
and forge ahead.
> - Data storage implementation details (how memory and disk was used)
We used to have an extensive database package in polyFORTH. We have
made a modified version to use for flash databases, which we'll probably
include in SwiftX at some point.
In embedded systems, it's important to manage ROM/Flash and RAM
carefully. We have tools in SwiftX to do this, reflected in the
proposed Cross Compiler Standard, discussed in
http://www.forth.com/downloads/ANS/XCpaper.pdf
> - Extensions to the compiler
You mean like custom structure words? They're discussed here far more
than they're used in applications, in my experience.
> - Modifications to the Forth system (extending the system into a new
> domain-specific environment)
Well, that's what an application is, isn't it? The boundary between
"system" and "application" is pretty fuzzy in the Forth world. Every
time we write an application we end up with a system adapted to support
that application domain. Makes it really easy to do similar projects.
For example, GE Multilin in Vancouver has a whole line of multiplexers
programmed in Forth, with a lot of shared code (see
http://www.forth.com/resources/appNotes/app-GE-Multilin.html).
> I'm eager to learn from the experience of others, to get a better idea
> of what is possible in Forth and expand my bag of tricks, if anyone
> has any interesting stories to tell or something useful to teach.
I also wish more of this lore could be captured and made available in
written form. Unfortunately, most of the programmers with good stories
to tell are too busy writing new apps to write about old ones, and most
companies consider their app code proprietary. I hope some other folks
here will chime in with more useful stuff.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
