2023-12-26 04:50:02 <olle        > \o
2023-12-26 04:50:07 <olle        > Merry Christmas and happy holiday :)
2023-12-26 05:31:49 <rendar      > merry xmas y'all
2023-12-26 09:57:23 <zelgomer    > why S" and not just " ?
2023-12-26 10:08:58 <olle        > zelgomer: i assume they are different words_
2023-12-26 10:08:59 <olle        > ?
2023-12-26 10:12:10 <zelgomer    > i'm asking why does forth tend to use the word S" to begin string literals instead of just " ?
2023-12-26 10:12:35 <zelgomer    > is there a good reason to call it S" instead of " ?
2023-12-26 10:17:30 <olle        > zelgomer: Someone decided that `"` is better to end a string with, maybe?
2023-12-26 10:17:36 <olle        > How else would you end a string?
2023-12-26 10:21:45 <thrig       > with scissors, or a fire
2023-12-26 10:24:54 <olle        > na na
2023-12-26 10:25:23 <olle        > I think it's related to the parsing capabilities of forth too
2023-12-26 10:25:32 <olle        > The end char "should" be a single char, not a combination of chars?
2023-12-26 10:25:40 <olle        > KipIngram and others can probably enlighten us :D
2023-12-26 10:32:11 <thrig       > " starting-or-ending a string would add state to juggle
2023-12-26 10:33:32 <olle        > gforth does support this, iirc
2023-12-26 10:38:03 <dave0       > S" is a forth word, but the terminating " is not
2023-12-26 10:38:45 <dave0       > iirc WORD can take a character as a parameter and it will return a (counted?) string that is terminated with that char
2023-12-26 10:38:51 <dave0       > it's like   .(   teminating with a )
2023-12-26 10:39:32 <dave0       > i think this can work for .(   ...      : .( [char] ) word drop ;
2023-12-26 10:41:30 <dave0       > you could always define " by hand    : " postpone S" ; immediate
2023-12-26 10:42:21 <dave0       > now i have to sleep
2023-12-26 10:42:22 <dave0       > nite all
2023-12-26 10:43:56 <olle        > \o
2023-12-26 11:01:57 <zelgomer    > olle, the terminating " is not a word in the forth dictionary, it's just a delimiter. there's no reason why you can't start and terminate with the same token
2023-12-26 11:02:07 <zelgomer    > yeah, dave0 beat me to it
2023-12-26 11:02:39 <olle        > Oh? Huh.
2023-12-26 11:02:52 <olle        > Then I'm also interested in the answer.
2023-12-26 11:03:46 <zelgomer    > i have always used " in my forths to begin strings. i ask the question because i'm wondering whether anyone has a good enough reason to convince me to adopt the more conventional syntax
2023-12-26 11:04:57 <thrig       > {...} or such would let you balance on braces
2023-12-26 11:06:09 <unjust      > if " works for you, why change it? but you might have support for different string formats - maybe you use " to introduce a NUL-terminated (C-style?) string and S" to introduce a counted (length data) string
2023-12-26 11:06:45 <olle        > wait, is S" a counted string in the standard?
2023-12-26 11:07:09 <olle        > Nah, two elems on stack
2023-12-26 11:07:46 <unjust      > ^ the count preceeds the text
2023-12-26 11:07:57 <thrig       > https://thrig.me/tmp/s-quote.txt
2023-12-26 11:09:09 <olle        > unjust: yeah but "counted string" sounds like that other thing when the count is in front of the string in memory
2023-12-26 11:09:27 <olle        > And you have to manually bend it out
2023-12-26 11:10:39 <unjust      > by taking the first byte (or cell, or whatever granularity fits your system) as the length, and advancing the pointer to obtain the character data?
2023-12-26 11:12:39 <olle        > yes
2023-12-26 11:12:52 <olle        > like a header, i guess
2023-12-26 11:13:49 <zelgomer    > unjust: i've done a lot of things over the years that i thought worked for me because i didn't fully appreciate the intention of the traditional form until it was pointed out to me. but beside that, it's just a personality thing, i guess. i'm always questioning the way i do things and continually trying to improve
2023-12-26 11:14:23 <GeDaMo      > I think the S is just a sigil for strings like float words begin with F
2023-12-26 11:14:59 <unjust      > olle: seen PLACE? https://forth-standard.org/proposals/place-place
2023-12-26 11:16:22 <olle        > unjust: nop, thanks :)
2023-12-26 11:18:07 <KipIngram   > olle: Counted string vs. C-style string is an interesting business.  Both structures have advantages and disadvantages.  E.g., counted string wins hands down on strlen().  For that matter, it wins on strcpy() too, since you can deply rep movs.
2023-12-26 11:18:55 <KipIngram   > And you could also argue that when you want to concatenate two C-style strings you have to "bend out" one of the null terminators.
2023-12-26 11:19:09 <KipIngram   > I.e., both structures contain data that isn't truly "string data."
2023-12-26 11:19:25 <olle        > Mm
2023-12-26 11:19:32 <KipIngram   > The count byte isn't "string data," but then again neither is that null.
2023-12-26 11:19:57 <olle        > True
2023-12-26 11:19:58 <KipIngram   > I wind up  using both in my system.
2023-12-26 11:20:24 <KipIngram   > EXPECT, QUERY, and so on work with C-style strings, but WORD produces a counted string form of the word it parses out.
2023-12-26 11:20:45 <KipIngram   > That just wound up being the cleanest way to craft the overall process (I thought, at least).
2023-12-26 11:21:28 <zelgomer    > my string literals tend to be both. in memory they have a null terminator and they're prefixed with their length (less the '\0'), and on the stack they are two cells: an address and a length
2023-12-26 11:22:07 <KipIngram   > zelgome: Actually, yes - in fact my WORD also null terminates that string, so I can treat it either way.
2023-12-26 11:22:20 <KipIngram   > One byte of storage waste, but... it's a transient data item anyway.
2023-12-26 11:22:20 <zelgomer    > i'm interfacing with a kernel written in c which expects those '\0's on filenames and such. so it's just sane to always have it there
2023-12-26 11:22:28 <KipIngram   > I don't include that null in my headers.
2023-12-26 11:22:57 <KipIngram   > "Sane" - that's a good way of putting it.  Things just seem to work out better.
2023-12-26 11:24:12 <KipIngram   > What I never do is "neither," which means you have to carry the length around on the stack and pass it through all of your algorithms.
2023-12-26 11:26:10 <KipIngram   > I may have fibbed a little up above about rep movs; I think there is a rep cmpsz type maneuver where you can use rep to scan for a trailing null.
2023-12-26 11:26:35 <KipIngram   > But then you'd still have to rep cmpsz to find the length and then rep movs to copy the string - two scans instead of one.
2023-12-26 11:31:49 <olle        > Well if you do a struct you get an explicit header :)
2023-12-26 11:31:54 <olle        > Type-safe too!
2023-12-26 11:31:54 <olle        > Kinda
2023-12-26 11:43:32 <KipIngram   > :-)
2023-12-26 11:43:51 <KipIngram   > So instead of p->data I just say 1+.
2023-12-26 11:44:34 <KipIngram   > I *treat* it like a struct - it's just not a compiler enforced thing.
2023-12-26 11:49:10 <olle        > Hehe
2023-12-26 11:59:22 <olle        > I wonder how much of traditional forth you can implement in a type-safe manner :d
2023-12-26 11:59:30 <olle        > 80%? 90%?
2023-12-26 12:50:19 <user51      > Is there anything fancier than the "standard"(?) REPL? For example, having the stack be visible at all times, or watching memory addresses.  This is the closest thing I can think of, and it's not Forth https://justine.lol/blinkenlights/
2023-12-26 12:51:43 <GeDaMo      > Does Factor have something?
2023-12-26 12:59:56 <user51      > Checked the site but coudln't find anything.  Maybe the answer is gonna be "depends on the Forth" again? :)
2023-12-26 13:18:06 <olle        > user51: which site?
2023-12-26 13:19:13 <user51      > olle: Factor's
2023-12-26 13:28:42 <olle        > Ah right
2023-12-26 13:54:35 <slacko_user13052> 200
2023-12-26 13:54:59 <slacko_user13052> ah, ignore that
2023-12-26 13:55:04 <GeDaMo      > 404! :P
2023-12-26 13:55:13 <slacko_user13052> yep
2023-12-26 13:55:20 <slacko_user13052> heh
2023-12-26 15:53:07 <DKordic     > zelgomer: S" is half-assed.  Straightforward _character_ string functionality _requires_ _Garbage Collection_!
2023-12-26 19:06:52 <slacko_user13052> garbage collection is for languages that are expected to produce garbage
2023-12-26 19:08:04 <slacko_user13052> I can;t recall who pointed it out, but languages that were designed for somone else (IE not the language designer) to use tend to be awful.
2023-12-26 19:09:09 <slacko_user13052> And that includes all of the classical garvage collected langs, IE java et al.
2023-12-26 19:11:47 <slacko_user13052> IIRC GO (googles language vefore carbon) has garbage colection. I haven't used it, but that lang may actually be good, or at least situationally good.
2023-12-26 19:35:06 <thrig       > on early lisp machines the GC was buggy so they instead just rebooted every few days
2023-12-26 19:35:39 <thrig       > the GC in Go is somewhat less terrible, things have being learned in the meanwhile
2023-12-26 19:36:57 <slacko_user13052> still buggy, though. meh.
2023-12-26 19:39:08 <slacko_user13052> I already have enough buggy stuff to deal with.
2023-12-26 19:57:39 <slacko_user13052> I suspect that GC's are one of those impossible problems that one should just avoid.