One of my goals for Forth in PLASMA was to easily write scripts to do things like installations. PLFORTH has access to all things PLASMA so I decided to show off my rudimentary BATCH style scripts for installing the PLASMA system on a hard disk. PLASMA has grown to fill many floppies @140K so installing to a hard drive (or some such medium 800K or larger) has become necessary. It has had to be done by hand up until now. You may ask why I would choose to run Forth in an interpreted mode instead of compiling it and running it that way, and I probably couldn't give you a very good reason except it feels more *BATCHy* that way. And you can intersperse word definitions, variable declarations and such in the most unstructured way possible. The biggest challenge was writing an immediate-mode conditional. I checked out some others' solutions but I decided to not compile any code and operate on the input stream directly. Since an install script is my first test, here is a snippet of the scripts:


DEST and FILELIST are strings that get built up preceding the call to LOADMOD which takes a module name and command line string. The LOADMOD sequence is setting up the command line to pass to the COPY and NEWDIR executable modules. Usually run interactively from the command line, PLFORTH is able to programmatically build the command line parameters and then call them with the module (all things in PLASMA are modules).

Two of the interesting words here are ?EXEC and RESUME>. The idea is to conditionally execute the code between them. I also needed them to nest. I'll admit to being quite the n00b when it comes to programming in Forth, so be kind.

Here is what I came up with for these words:


The other words are pretty small and just get input from the user to confirm whether to conditionally execute the following code or not and wait for a key press when a floppy disk needs to be swapped in. And it all works just as I envisioned.

....and just like that I screwed it up. Anyone catch where I referenced ?EXEC inside the definition of ?EXEC ? In cursory testing it worked until I said 'No' to the build tools but it still asked for the Forth sample scripts. The ' ?EXEC inside the definition actually compiled a zero so it never matched and threw the whole nested count off.

Here is the revised version that uses variables to capture the addresses of ?EXEC and RESUME> for later testing. I know how other languages refer to functions not yet defined (PLASMA uses predef), but I'm unsure how Forth handles it.

I had not. I will admit that Forth naming conventions drive me a little crazy. Bracketed, parenthesized, etc. version of other words seems to be more confusing than just picking a new name. I understand that Chuck M. went more down the path of different words for interpreted vs. compiled versions. I can't decide if that is beneficial or not. In my case, I decided on names that seem to flow better with the use case of a batch file environment, but that could just be me. I went with the '?' in front if EXEC because its a conditional, and the following '>' on RESUME to add closure but also avoid the case where a valid usage of RESUME existed, in a string for instance.

Do you feel its better to stick with (one of) the Forth standard, or go with what feels consistent with the particular usage? I'm definitely on the fence. And thanks for your time!

Thank you very much for the information on LATEST and UNLOOP! Added both to PLFORTH which nicely fixed my ?EXEC implementation and cleaned up one of my samples that exited inside three LOOPs. Much better. I'm slowly wrapping my head around the evolution of Forth to the semi-modern days.

One thing is to disentangle the two. Some people building Forths like to use () around names for inner routines that are not intended to be used in "userland", and/or for names of routines (either Forth or machine language stubs) that are not appropriate for the outer-interpreter to execute.

For instance, in a direct-threaded Forth, a compiled word starts with a call or jump to a hardware routine which pushes the IP and gets things set up for the inner interpreter to execute the following list of word addresses. The people who like the parentheses words might (ENTER) or (LIST) ... (list of word addresses, that is, not "print to screen") ... but I don't like that style of naming, and I'd call it doENTER or doLIST.

The bracket-y words are something else. When compiling, "... [ <name> ] ..." drops into interpreting state, executes <name>, and then goes back into compiling mode.

So if you have a word that is NOT immediate, which you would often use while compiling with [ ] brackets around, and then you make an immediate version of that word with behavior that works whether you are in compiler or interpreter state, it's a common shorthand to put brackets around it.

And that is what [IF] ... [ELSE] ... [THEN] ... are. They are extremely useful for conditional compilation, and in that context, the surrounding brackets are a visual reminder that they are going to execute, not be compiled.

They are also quite useful for batch processing. In that context, the immediacy is not an issue, but even if you mostly use them for batch processing, using them in the form that also works well when doing conditional compilation means that you already have that tool in your toolkit when needed.

And once you have them, you have multi-line comments for free, using the "0 [IF] ... [THEN]" pattern.



While I think that the question of the style of Forth that is most convenient to use to program for matrix networks of Forth processors is an intriguing one, most people who would be using Forth for your kind of application stick to conventional Forth.



Note that if you are defining a word with behavior that isn't in a standard word, the most important thing is to avoid giving it the same name as a standard word, which will end up causing confusion if people are trying to refine it or port it for their own use. If you have a word that doesn't work like Forth20xx [IF] ... definitely don't CALL it [IF].

And if you are doing batch processing, you'll want more than just [IF] [ELSE] [THEN] ... you need a batch processing form of a looping constrict, for example ... so there is plenty of opportunity to name your own words your own way.

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

Yes, while the Commander X16 allows 80 column text, if the same source is going to work in ASCII mode, in PETSCII Graphics mode and PETSCII Upper/Lower mode, the words should be all upper case in ASCII & PETSCII Graphics, which means they are lower case in PETSCII Upper/Lower mode.

Horses for courses.

Many thanks for everyone's contributions. I started out targeting the old figForth words and as such did use the '(' ')' for the compiled version of the immediate words. As I am also targeting the Apple ][ (among other models), upper-case only and 40 columns is one of the limitations for name choices. After all the feedback (and great links - thanks Jim) I've been slowly aligning my word names with more current implementations. While writing more demo scripts to exercise different parts of the system, the need for DEFER came up. Although not a batch script, it shows off the power of DEFER/IS. I realized DEFER is nothing more than a function (word) pointer and can be used with multiple IS invocations to alter its function. To that end, it works as a nice plotting calculator - just update the DEFERed function with IS and get a new plot. Here is a simple program with a tall stack of PLASMA libraries implementing floating point through the Apple SANE library (quite extensive but very slow) and hi-res graphics:


(yes, I realize the plots are inverted. WIP)

One setting where DEFER can be real handy is where you have mutually recursive words -- say, a pair of words where each word may, depending on state, call the other word. If you define "Word1" first, and "Word2" second, you can:

DEFER Word1

: Word2 ( ... ) ... ;

:NONAME \ Word1 ( ... )
... ; IS Word1

(or if you don't have :NONAME, " : doWord1 ( ... ) ... ; ' doWord1 IS Word1")

Yes, I believe this was the original intent of DEFER, to pre-declare a function so it can be referenced before being defined. But given the implementation, it can be so much more. I'm a fan of function pointers, so I'll be using this quite a bit.

If you are a fan of function pointers, I hope you have seen mini-oof ("mini-object-oriented-forth): https://bernd-paysan.de/mini-oof.html