I'm working on Tali Forth 2 (an ANS 2012 STC Forth) and I'm looking for others' thoughts/suggestions on making REFILL extendable. The ANS 2012 is important as DPANS94 (I think) changed how the input is parsed and allows using any string/buffer in memory as the input buffer (eg. strings are often just made the input buffer temporarily to evaluate them rather than copy them into a separate input buffer). I think DPANS94 also added SOURCE-ID to BLK to indicate if the input was a block/screen or a file.

REFILL will be in ROM, and is called by words that are also in ROM ( QUIT and S" ). I'm really only concerned with S", as QUIT will restore input to be from the console and REFILL knows how to handle the console. I'd like S" to be able to handle long strings in files.

My current thought is to introduce a user variable 'USERREFILL (or something like that) where the user can put their routine. This will be called first in the ROM version of REFILL, and the result code on the stack will tell REFILL if the user's version handled things, or if REFILL should run the rest of it's code. That might look something like (untested):

Code:

: REFILL ( -- f)
   'USERREFILL EXECUTE ( Run user's version of REFILL )
   ?DUP 0= IF ( See if user's version of REFILL worked)
      ( * User's refill didn't do it... put rest of code currently in REFILL here *)
   THEN ;

On startup, the user variables that Tali2 starts with are copied to RAM from a table in ROM, so I can just arrange to put the XT for 0 (zero is a word in Tali2) into 'USERREFILL for initialization. That way, when REFILL is called, it will execute 0 and therefore get a 0 on the stack to indicate that the user's refill did not refill the input buffer and perhaps REFILL should try to do it the normal way. When a user adds file support, they can write their own file-aware routine and put its XT into 'USERREFILL. That routine would return TRUE if it handled the request and FALSE if REFILL should attempt to do its normal thing.

I may need to make REFILL a little smarter so it can handle an end-of-file in the middle of an S" string. It will have BLK and SOURCE-ID to look at, so it will be able to tell if the USERREFILL routine *should* have been the one to refill the input buffer.

Are there other methods of making an extendable word in ROM, whereby other ROM words will get the new functionality?

That sounds very similar to how Tali2 handles the input/output words. There are words INPUT and OUTPUT that return the location of the vector (not the vector itself) in RAM. There are also vectors in ram for reading and writing blocks. These vectored words don't work quite the same as a deferred word in Tali, but it has the same overall effect and indeed the vectors for the implementations in ROM are copied into RAM at startup like you describe.

The I/O vectors are currently held in zero page, but zero page was starting to fill up (Tali tries to leave half of zero page for applications to use) so the block read/write vectors ended up in what Tali calls "User variables". This is a spot in the dictionary with 256 bytes (128 cells) alloted and the variables here are indexed from a base pointer which is in zero page. When Tali2 eventually gets tasking, the idea is to have one set of user variables for each task and only the base pointer needs to be swapped in zero page to load that tasks' set of variables.

My original proposed solution was to have some kind of vectored word that REFILL would call, but you seem to be suggesting vectoring REFILL itself and I think that is probably more the "Forth way" as my replacement REFILL can always call the ROM version.

REFILL is only called when the interpreter runs out of text or for very longs strings (Tali2 supports strings longer than 256 bytes), so there's virtually no performance penalty to vector it.