2024-01-17 16:38:22 <zelgomer    > does anyone know what an old-school forth would do if a quote like S" was unterminated by the time it reached the end of a block? would the runaway string parsing carry over into the next block it tries to load, or did it detect that?
2024-01-17 16:38:57 <KipIngram   > I imagine you'd find that varied from system to system.  It certainly SHOULD be checking for end of block.
2024-01-17 16:39:08 <KipIngram   > I think, at least.
2024-01-17 16:39:34 <KipIngram   > In one of my systems I checked >IN for that, in WORD.
2024-01-17 16:39:49 <KipIngram   > And you'd expect S" to use WORD for its parsing.
2024-01-17 16:41:24 <zelgomer    > i don't think so. word throws away the whitespace between words, but S" would want those
2024-01-17 16:42:53 <KipIngram   > Sometimes word accepts the delimiter as a parameter, and that's what it treats as "whitespace."
2024-01-17 16:43:01 <KipIngram   > For example, often you have
2024-01-17 16:43:17 <KipIngram   > : (  <close paren value> WORD ;
2024-01-17 16:43:48 <KipIngram   > But in "old" systems you're dealing with a standards-absent thing, so you'll find a lot of system-to-system variation.
2024-01-17 16:44:35 <zelgomer    > i see
2024-01-17 16:45:36 <KipIngram   > Some systems might not give WORD a parameter - I regard that as considerably less useful.
2024-01-17 16:46:10 <zelgomer    > i did something similar in mine, but i have a bug that you can't write empty strings. S" "  <-- the space is the terminating whitespace for S", and then the leading " is seen as a leading delimiter and is ignored. i have plans to fix it, just haven't gotten around to it yet. but i wonder how that was handled in the systems you describe
2024-01-17 16:48:05 <zelgomer    > i actually pass a callback to a generic parsing function. e.g.,  : word? ( -- 0 | a u -1 )  [: ' !' [ ' ~' 1+ ] LITERAL within ;] parse? ;  something like that... there's a little more to it, but you get the idea
2024-01-17 16:49:14 <KipIngram   > That leading " should be part of the S" word and wouldn't be seen again once you'd looked S" up in the dictionary.  >IN should be pointing at the space when S" executes.
2024-01-17 16:49:40 <KipIngram   > And if all it does is seek the next " then yes - it would see the space a spart of the string.
2024-01-17 16:50:12 <KipIngram   > Actually, on thinking about it, really >IN should point to the closing " when S" executes.
2024-01-17 16:50:20 <zelgomer    > yes, that's what i thought
2024-01-17 16:50:24 <KipIngram   > The space was consumed by the "termination" of parsing out S".
2024-01-17 16:50:33 <KipIngram   > So I would expect that to give you an empty string.
2024-01-17 16:50:58 <zelgomer    > but once S" starts executing, the lone " is a delimiter
2024-01-17 16:51:09 <zelgomer    > and word would skip over the leading delimiter
2024-01-17 16:52:11 <zelgomer    > word has two loops, right?  <key and drop until you get a non-delimiter> <key and store until you get a delimiter>
2024-01-17 16:55:36 <KipIngram   > Well, if WORD consumes the trailing space as normal operation, then you can just assume the leading delimiter has already been "handled.'
2024-01-17 16:55:48 <KipIngram   > I see your issue, though.
2024-01-17 16:56:10 <KipIngram   > If you had multiple spaces between words you'd only use the first one as the terminal delimiter, and you still want to skip over the others.
2024-01-17 16:56:19 <KipIngram   > That is kind of a nasty situation.
2024-01-17 16:56:39 <KipIngram   > And what if you WANT spaces in your string at the start?
2024-01-17 16:56:43 <KipIngram   > It can't skip over those.
2024-01-17 16:57:05 <KipIngram   > You're right - it's a little messy and I think it would require some "special case decisions" be made in the case when the delimiter is space.
2024-01-17 16:57:43 <KipIngram   > I'll have to go and see how my WORD handles this.  I haven't added S" yet, so I haven't bumped up against this.
2024-01-17 16:57:48 <thrig       > retroforth converts _ to spaces
2024-01-17 17:08:46 <zelgomer    > : S""  pad 0 ;  :)
2024-01-17 17:11:29 <GeDaMo      > Nice :)
2024-01-17 17:12:10 <GeDaMo      > : 0 0 ;  : 1 1 ;
2024-01-17 17:12:49 <zelgomer    > we're forth pros
2024-01-17 17:12:56 <GeDaMo      > Some older Forths would define 0 and 1 so they would be found early in the dictionary search and not have to go through the whole thing and then convert to a number
2024-01-17 17:15:21 <KipIngram   > :-)  that might be the easiest way out.
2024-01-17 17:15:26 <KipIngram   > and very forthy.
2024-01-17 17:16:00 <KipIngram   > Having 0 and 1 words also saves a bit of space in most systems, since they get used quite a lot.
2024-01-17 17:16:18 <KipIngram   > and might be a shade faster too.
2024-01-17 17:25:36 <KipIngram   > Execution-wise I mean; they're certainly faster compile-wise.
2024-01-17 17:26:07 <KipIngram   > Also, if your system is code threaded they inline very  nicely.
2024-01-17 17:26:34 <KipIngram   > though I guess any literal number would inline well.
2024-01-17 18:21:25 <crc         > re: old-school S": my earlier systems would continue parsing until the termination character was found
2024-01-17 18:34:28 <crc         > if the " termination wasn't found in the blocks or file being evaluated, it'd continue to consume input from the keyboard until it was found.
2024-01-17 19:00:34 <zelgomer    > crc: cool, thanks. that is of course the easiest way to do it. debating whether i should bother to fix that or not
2024-01-17 19:02:01 <crc         > I never found it to be a problem in actual use.
2024-01-17 19:39:45 <lispmacs[work]> maybe offtopic, but wondering if anybody here ever used QNX OS or Watcom compiler
2024-01-17 19:45:30 <GeDaMo      > I think I played with the QNX demo disk that was about in the 90s
2024-01-17 20:09:09 <crc         > I played with the QNX demo disk as well, many, many years ago
2024-01-17 20:11:02 <crc         > on watcom, I've run it on a DOS system
2024-01-17 20:33:26 <KipIngram   > @crc: Oh, dynamically switching from block input to keyboard input like that is neat - that could be put to some useful purposes, I think.
2024-01-17 20:33:47 <KipIngram   > I've often wished redirection of stdin in Linux worked that way.
2024-01-17 20:34:08 <GeDaMo      > Can't you use cat for that?
2024-01-17 20:34:30 <KipIngram   > Probably.
2024-01-17 20:34:43 <GeDaMo      > - for standard input
2024-01-17 20:34:45 <KipIngram   > I'm "sort of handy" with Linux but definitely not a wizard.
2024-01-17 20:35:15 <crc         > my input is all vectored through `c:get`; I just change the input source and switch back to stdin when EOF or end of block is reached
2024-01-17 20:35:54 <crc         > GeDaMo is correct on cat and -
2024-01-17 20:36:23 <GeDaMo      > cat x - | ... contents of x followed by stdin
2024-01-17 20:43:42 <zelgomer    > not quite the same thing, though. your stdin won't be line-buffered
2024-01-17 20:44:11 <zelgomer    > oh, it does work
2024-01-17 20:44:18 <zelgomer    > nevermind then
2024-01-17 20:52:12 <thrig       > there are kluges that can change the buffering style
2024-01-17 21:10:29 <KipIngram   > What does the - do there?
2024-01-17 21:11:03 <thrig       > - is a convention for "read from stdin"
2024-01-17 21:11:29 <KipIngram   > I didn't know that.  That explains why I've gotten odd behavior at times.
2024-01-17 21:11:33 <KipIngram   > Cool.
2024-01-17 21:12:22 <thrig       > https://thrig.me/tmp/awk.txt (and Perl, etc etc etc)