EMPTY-BUFFERS effect on BLK ?

[SirWumpus]

Should EMPTY-BUFFERS set contents of BLK to zero? If all the blocks are unassigned by EMPTY-BUFFERS then there is no current block being interpreted; should BLK reflect that condition?

[ruv]

Should EMPTY-BUFFERS set contents of BLK to zero?

It should not. Because formally the block will remain the input buffer anyway. Then, it's incorrect to invoke EMPTY-BUFFERS when BLK is not zero. Then, an implicit ambiguous condition exists in this regard. Then, EMPTY-BUFFERS may throw an exception in this case.

Probably, it should be declared explicitly: an ambiguous condition exists if BLK contains a non-zero when EMPTY-BUFFERS is invoked.

[gerryjackson]

Have you see the Technical Committee's reply to RFI 0006 that contains the following towards the end of the discussion:
"... both the letter of the standard and the intent of the TC are that EVALUATE strings be processed in place. ... the Standard clearly states that the EVALUATE string is the 'input buffer' ..."

You might disagree with the the word 'clearly'.

[ruv]

@gerryjackson, thank you! I was just writing an update to my post in this regard.

According to the testcase, in case of evaluate the standard guarantees that the input buffer is the same (before and after), and it may be passed to a nested invocation of the Forth text interpreter.

Then my questions remain relevant only for files, blocks, and the user input device (it cannot be nested, but can be the initial input source).

[forthy42]

Historically, Forth systems didn't have ample of RAM. In-place zero copy evaluation therefore is what's expected. Using one single buffer for all file inputs is possible, too (though most file-system based Forths have enough memory and don't need this); just for terminal input, you can't reuse the buffer, because you have no way to reread the same input again.

I would suggest to read the “make block u the input source” literal: SOURCE is equal to BLK @ BLOCK B/BLK. The “encompass” in the text is best interpreted this way. BLK @ IF BLK @ BLOCK ELSE TIB @ THEN is what you find in fig-Forth where SOURCE should have been factored out. Screen 47:

https://github.com/ForthHub/FIG-Forth/blob/master/fig.fth

[SirWumpus]

Forth draft 19-1 section 3.3.3.4 Text-literal regions

A system must provide at least two transient buffers for use with C", S" and S" strings.

So PARSE-NAME uses the input buffer and S" uses a transient buffer in interpretation state. So the test should always return TRUE (-1)

parse-name foo  s" ( sd -- flag ) parse-name foo compare 0=" evaluate .

Section A.11.6.1.1717 INCLUDE-FILE proposes two methods methods for input; the first case would reuse the same input buffer, the second would use different line buffers.

2. Allocate a separate line buffer for each active text input file, using that buffer as the input
   buffer. This method avoids the “seek and reread” step, and allows the use of “pseudo-files”
   such as pipes and other sequential-access-only communication channels

For a hosted Forth, I suspect the second method is used and the suggested test again returns TRUE.

[ruv]

So PARSE-NAME uses the input buffer and S" uses a transient buffer in interpretation state. So the test should always return TRUE

Yes, in case of evaluate the test is always true.
But what if this string will be a block content interpreted by load (instead of evaluate), or a file content interpreted by included?

parse-name foo  s" ( sd -- flag ) parse-name foo compare 0=" evaluate .

2. Allocate a separate line buffer for each active text input file,

For a hosted Forth, I suspect the second method is used and the suggested test again returns TRUE.

Agreed.
The only question is: do we know of any Forth system (claimed to be at least a Forth-94 standard system) that uses the first method, or some another method that invalidates the address and/or content of the input buffer?

[MitchBradley]

When I started doing Forth in 1982, there was a slight justification for using blocks on 8080 machines with 5.25" floppy drives, but within a few years it became so much easier to use files. By the time the standard was published in 1994, even most of the old-school die-hards were using files. We kept blocks in the standard just because a few people were nostalgic. Now, 30 years later, with a Moore's Law exponent of 10, it is hard to imagine that anyone still cares about the BLOCK subsystem.

[SirWumpus]

I think the BLOCK subsystem (even as a block file) is cool, easy to implement quickly, a smaller word set than the File Access, and probably still of interest for embedded systems.

[SirWumpus]

The only thing I wish was possibly was to have some means to set the block size; maybe define the block size in the first cell of block 1 or by LOADing block 1, but that's just a minor thing. Having 4K or 8k blocks might be more useful for modern mass storage.

[SirWumpus]

For example

BLK-SIZE @ 1024 = IF 8096 BLK-SIZE ! 1 LOAD THEN

( continue using the extended block size)

[MitchBradley]

I do a lot of embedded work on ESP32 MCUs that cost less than $2 and have a minimum of 8MB of FLASH storage that can be managed as files via a LittleFS filesystem that is well-supported by the SDK. I guess if you are writing a bare-metal Forth from scratch, you could get something working with BLOCK with less code, but probably not more quickly compared to using the existing SDKs. Bare-metal was useful to me 15 years ago when I did the Forth firmware for the One Laptop Per Child computer and we needed to have control over every line of code for security considerations, but the number of people who do stuff like that anymore is very close to zero. Even then, it used files, because I had implemented open source Forth code for multiple standard file systems long before.

[ruv]

I think the BLOCK subsystem (even as a block file) is cool, easy to implement quickly, a smaller word set than the File Access, and probably still of interest for embedded systems.

Blocks seem to map easily to sectors of a mass storage device. Therefore, some simple file system can be implemented as a standard program using the Block word set. Maybe just like a toy.