2022-07-29 03:28:46 <neuro_sy`   > I should learn to love BLOCKs instead of the filesystem (open-file close-file)
2022-07-29 03:38:31 <neuro_sy`   > I kind of feel like Forth 83 is saner than ANS.
2022-07-29 03:47:40 <thrig       > bloat is fractal
2022-07-29 03:53:23 <veltas      > neuro_sy`: FORTH 83 is saner than ANS, but good luck finding Forth 83 words in your modern forths
2022-07-29 03:53:37 <veltas      > I prefer ANS right now because it's a good mix of compatible and not bloated and dumb
2022-07-29 03:53:50 <veltas      > Unforuntately there is still dumb bloat but less than Forth 200x
2022-07-29 04:04:22 <neuro_sy`   > The GameOfLife code here looks neat: https://wiki.c2.com/?GameOfLife
2022-07-29 04:04:34 <neuro_sy`   > Woops sorry, I mean here: https://wiki.c2.com/?ForthBlocks
2022-07-29 04:04:46 <neuro_sy`   > I pasted the first link wrong.
2022-07-29 08:30:25 <veltas      > Don't know if neuro reads the log but https://github.com/Veltas/sf-editor/blob/master/sf-editor.fs
2022-07-29 08:31:14 <veltas      > And I think blocks are bad, from my own experience, but I don't have a lot of experience with them
2022-07-29 08:31:51 <veltas      > I especially dislike the way the block is just one big line, so you cannot have a word ending on last column, there needs to be a space there or next line
2022-07-29 08:32:59 <veltas      > Which also adds complexity to the definition of \ which is ironic because the only real 'feature' of this big line input thing is using ( to comment a whole block
2022-07-29 08:33:16 <veltas      > So we make one word easier by making another (and all block source) harder
2022-07-29 08:46:35 <veltas      > The only good def of \ is    : \  0 parse 2drop ; immediate
2022-07-29 09:20:43 <dave0       > my parse stops at newlines
2022-07-29 09:22:35 <dave0       > my word, on the initial skip of whitespace, goes past newlines .. but that's not standard
2022-07-29 09:23:59 <dave0       > i think i saw someone use   : \  refill drop ;
2022-07-29 10:32:32 <KipIngram   > veltas: You can arrange to have the last byte of a block contain a word character, but it means a bit of special handling.  WORD just needs to know to stop there.  I.e., for 4kB blocks, WORD stops at >IN=4095.
2022-07-29 10:33:38 <KipIngram   > Somewhere in my word if it sees >IN try to go to 4096 it just returns a null.
2022-07-29 10:34:25 <KipIngram   > I did that in mine just so I wouldn't have to have a null pad byte after each disk buffer - I wanted them packed as an array of buffers.
2022-07-29 10:34:36 <KipIngram   > So that they were all 4096 byte aligned.
2022-07-29 10:45:27 <KipIngram   > I think being "opposed to blocks" is a bit of a funny attitude - every storage device out there works at the lowest level in such a way.  You may prefer to have it hidden below some code you regard as more "friendly," but it's always there somewhere.
2022-07-29 10:45:46 <KipIngram   > Offering the block layer is just Forth giving you low level control over your resources.
2022-07-29 10:46:18 <KipIngram   > You're certainly allowed to impose a more sophisticated layer over that.
2022-07-29 10:47:38 <KipIngram   > One might even argue that Forth offers too much functionality - the way it usually manages disk buffers automatically.  The "minimum" would just be to give you block-read ( addr n --) and block-write ( addr n --) and leave it at that.
2022-07-29 10:48:07 <KipIngram   > Well, maybe you'd also want to be able to specify a number of contiguous blocks.
2022-07-29 10:49:30 <KipIngram   > Oh, and you're also totally free to write your Forth so that it takes input from a disk buffer by lines, using newline as a separator.  It's just  not the way it was done historically.
2022-07-29 10:50:08 <KipIngram   > I allow newlines in my disk buffers, for editing purposes, but WORD treats them as spaces.
2022-07-29 10:50:42 <KipIngram   > Just substitutes a space so far as the higher levels of code are concerned.
2022-07-29 10:51:05 <KipIngram   > I rather like having one call to INTERPRET get a whole block.
2022-07-29 10:51:35 <KipIngram   > Simplifies the LOAD code.
2022-07-29 12:35:13 <veltas      > KipIngram: It's not really special handling, the block is 4K or whatever in size, you always need to handle the end of the buffer
2022-07-29 12:35:25 <veltas      > Whether it's a block buffer or command-line input buffer
2022-07-29 12:36:03 <veltas      > I guess my issue is more with how block source parsing is treated, rather than blocks in general
2022-07-29 12:36:17 <veltas      > Although to be fair FORTH blocks don't match physical blocks most of the time
2022-07-29 13:59:39 <KipIngram   > Well, if you guarantee that there's a null at the end of the useful material, then that handles ending the LOAD for you - you don't have to do an explicit "end check."
2022-07-29 14:00:09 <KipIngram   > Well, in typically implemented systems, at any rate, where a null gets parsed as a null word and terminates INTERPRET.
2022-07-29 14:00:39 <KipIngram   > You wouldn't even need to know how big your disk buffers were - just that you were certain to hit a null before you ran off the end.
2022-07-29 14:01:48 <KipIngram   > I'm giving serious consideration to having LOAD, if it reaches the end of a disk buffer without encountering a null, just continue right on into the next block, even if the split occurs in the middle of a word.
2022-07-29 14:02:03 <KipIngram   > It seemed to me that might provide the best "starting point" for later implementation of a file system.
2022-07-29 14:02:21 <KipIngram   > I haven't actually put that in and tried it, though.
2022-07-29 16:24:44 <veltas      > KipIngram: How to handle parsing to something other than 0 though?
2022-07-29 16:24:58 <veltas      > Surely that would run off the end?
2022-07-29 16:25:08 <veltas      > Or do you accept 0 as a universal delimeter
2022-07-29 16:28:25 <veltas      > Well it's official, I'm unemployed
2022-07-29 16:28:35 <veltas      > For two days before my new job starts
2022-07-29 16:53:57 <KipIngram   > Yes - null char is a universal delimiter.  It terminates the parsing of a word.  If no other characters have already been acquired for a word, then the acquired word is itself the null word.
2022-07-29 16:54:29 <KipIngram   > And that's in my dictionary as an immediate word; it's basically ;; (double return), so it returns back out of the infinite loop in INTERPRET.
2022-07-29 17:57:36 <KipIngram   > Oh, and >IN doesn't skip past it.  That way it can terminate another word and then still be there to be picked up alone the next time.
2022-07-29 18:32:11 <veltas      > KipIngram: There's words, and then there's parsing. They're two different things
2022-07-29 18:32:35 <veltas      > So what is 0 a word *and* also a universal delimiter?
2022-07-29 18:33:35 <KipIngram   > Well, in my system that's exactly how I use it.
2022-07-29 18:33:42 <KipIngram   > That's why I don't advance >IN past it.
2022-07-29 18:35:00 <KipIngram   > If "SWAP\0" (\0 is null) is at the end of a block, then \0 terminates SWAP.  Then it gets seen a second time the next time WORD is called, and it terminates WORD again.   But the word buffer was initialized to an empty string, so that empty string gets returned as the next word.
2022-07-29 18:35:25 <KipIngram   > so I suppose technically \0 in the *block* is a universal terminator.
2022-07-29 18:35:37 <KipIngram   > The null *word* is what the WORD buffer was initialized to.
2022-07-29 18:35:58 <KipIngram   > I have no idea if it meets all of some fancy list of CS theory criteria.
2022-07-29 18:36:01 <KipIngram   > But it "works."
2022-07-29 18:36:05 <KipIngram   > The way I want it to.
2022-07-29 18:36:48 <veltas      > I'm not trying for fancy CS theory
2022-07-29 18:36:52 <KipIngram   > I didn't invent the idea or anything.  It's the way things were described in McCabe, Forth Fundamentals.
2022-07-29 18:37:10 <veltas      > I'm just trying to understand what you are talking about, it sounded like two things mixed together
2022-07-29 18:37:14 <veltas      > with hand-waving
2022-07-29 18:37:21 <veltas      > And now I know that it is indeed two things
2022-07-29 18:37:27 <KipIngram   > I suppose you could say that the null word is the default response of WORD, if it doesn't find anything in the buffer.
2022-07-29 18:37:53 <KipIngram   > Yeah, I see that too after thinking about it a little.
2022-07-29 18:37:58 <veltas      > I've not read Forth Fundamentals
2022-07-29 18:38:17 <KipIngram   > There's the null char in the disk buffer or TIB, and there's the null *word*, which just happens to be what WORD will return if it sees no chars.
2022-07-29 18:38:41 <KipIngram   > I doubt you need to at this juncture, but it was of great value to young me.
2022-07-29 18:39:05 <KipIngram   > I didn't really have a clue how simply Forth could be put together before I read it.
2022-07-29 18:39:26 <KipIngram   > I had written something that "worked," but it was fairly ugly, I saw later.
2022-07-29 18:40:31 <veltas      > "I doubt you need to" maybe not *need* but I always learn something from Forth material
2022-07-29 18:40:44 <veltas      > I don't know that much, and I'm happy to learn whatever I can
2022-07-29 18:43:22 <KipIngram   > Anyway, I think you called it right to start with - tib null byte is a universal terminator and also a "barrier" to further penetration into the buffer.
2022-07-29 18:44:17 <KipIngram   > And also >IN==4096 is a barrier to further penetration and causes a null byte to be returned.