> roger.l...@gmail.com wrote:

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

>

>> I've read and own both Starting Forth and Thinking Forth. I treat
>> them like bibles and re-read Thinking Forth for fun/encouragement
>> often. Though the knowledge in them is starting to get a little
>> stale ...

>
> Starting Forth is very stale, particularly the paper copies (the online
> versions have been partially updated). Since you say you have
> SwiftForth, you have a copy of Forth Programmer's Handbook (pdf). You
> might benefit from Forth Application Techniques, and it's pretty cheap.
>

>>> Most of our application work nowadays is in embedded systems, which is
>>> reflected in my comments below.

>

>> It's frustrating; I know that embedded is where Forth thrives today.
>> But as I want pretty badly to become comfortable in Forth to build my
>> own apps on Windows, I puzzle without knowing for sure what works and
>> what doesn't and often I feel like I'm needlessly re-playing history,
>> and one that I don't quite understand. I'd like to see more source
>> code from serious applications, even if they're old, so long as they
>> competed with the other apps from their time. Ones written in "good"
>> Forth style, not some of the sources I've seen that look just like C
>> code with lots of nesting, long definitions, each line with a comment
>> basically repeating the statement...

>
> There's a fair amount of sample code with SwiftForth. Although they
> aren't large real-world apps, they do illustrate useful approaches. And
> I highly recommend the SwiftForth email group -- a number of the folks
> there have very complex apps, and they can certainly share Windows
> experiences and code. They don't chatter a lot, but are always willing
> to respond to questions, like "how would you go about doing ?"
>
>
>

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

>

>> Interesting idea. I can't read the code (probably because I don't
>> have that much experience in embedded programming) but here's a
>> question I want to know: Were the words for defining the bit patterns
>> defined just before this code, or as part of the support code for the
>> entire app?

>
> They are support code for configuring a 68332 for any application. Each
> of these words is executed interpretively to set a bit in the
> chip-select table to configure the chip. I've seen similar strategies
> used to initialize other kinds of tables, but this example was easy to find.
>

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

>

>> I know you said you don't use them often in apps but how have you used
>> them?

>
> In applications where the user interface involves typing Forth words,
> it's sometimes desirable to have a closed wordlist of user words, so
> users can't/won't inadvertently type words that could cause trouble.
> Those user-level words can have a lot of checks built in.
>

>>> Not sure just what you mean, here.

>

>> It's from something I read by Dr. Ting. I guess basically it means,
>> taking advantage of the data stack to improve readability simply.

>
> ("Featuring the data stack") Well, if I had a word that recorded a data
> sample, I'd call it SAMPLE. To take samples, I'd define something like:
>
> : SAMPLES ( n -- ) 0 DO SAMPLE LOOP ;
>
> ...because if elsewhere in the program you see
>
> ... 100 SAMPLES ...
>
> it will be pretty obvious what's going on. The relationship between a
> single and plural noun plus the obvious use of the stack aids readability.
>

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

>

>> What forms have these arrays taken? Are they usually a cell wide, or
>> have the been other data-widths? Have you made use of 2D arrays? Do
>> you use the [] suffix? What has/have been the most readable form(s),
>> if not that?

>
> It totally depends on the data. The thing is, that you can define data
> structures to accommodate the natural "shape" of the data, rather than
> having to mush the data into a predefined structure. Arrays can have
> byte elements, string elements, cell elements, double-cell elements,
> floating point elements, whatever your app calls for. They can be 1D,
> 2D, 3D, whatever fits its inherent structure. I'm unfamiliar with a []
> suffix.
>

>> What have circular buffers been useful for?

>
> Two very different examples:
>
> a) polynomial coefficients: each time you invoke the name of the array
> you get the next one, and it cycles automatically.
>
> b) a data buffer, into which one task or an interrupt routine is putting
> data, and another task is taking it out for further processing. Two
> pointers, one where to put the next sample, one where to fetch the next.
> Obviously the sample rate has to be slow enough (or the processing
> task fast enough) that they don't wrap inauspiciously.
>
> There are many more, but these two come to mind.
>

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

>

>> Ah, OK, so you don't try to make as many words as possible "global"?

> They may be technically global, but only interesting within a particular
> section of the code. I see no reason to be paranoid about global names
> (or variables).

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

>> I implementing a fairly complex set of structures
>> for my library to implement a decentralized external object management
>> system. ...

> You're talking about data structures, here, aren't you?

> Well, the system itself is organized into a number of files, ....