2024-05-07 03:17:45 <lf94        > How do I split a string by a space
2024-05-07 03:17:55 <lf94        > str str.len [char] ??? $split
2024-05-07 03:18:03 <lf94        > How do I specify a space where ??? is
2024-05-07 03:20:00 <lf94        > err, not $split, but scan
2024-05-07 03:23:10 <KipIngram   > Old Forths used to have a pair of words SKIP and SCAN that were used by WORD to do its business.
2024-05-07 03:23:29 <KipIngram   > I think SKIP skiped over white space, and SCAN then extracted up to the next white space.
2024-05-07 03:23:51 <lf94        > got it, BL
2024-05-07 03:23:53 <KipIngram   > WORD or BL WORD will hand you the next word from the input buffer, but it's generally specific to the input buffer.
2024-05-07 03:23:58 <lf94        > BL is what I nedeed :)
2024-05-07 03:23:59 <KipIngram   > Oh - that bit.
2024-05-07 03:24:01 <KipIngram   > Yeah.
2024-05-07 03:25:06 <KipIngram   > You know, in all my hardware Forth musings, I've presumed I'd have separate fetch and execute units.  Fetch's job would be, among other things, to work down through calls until it found opcodes, which it would forward to execute.
2024-05-07 03:25:24 <KipIngram   > And of course I've always been aware of the issues raised by conditional jumps in such a system.
2024-05-07 03:25:32 <KipIngram   > But I just realized tonight it's worse than that.
2024-05-07 03:25:40 <lf94        > scan ( c-addr1 u1 c – c-addr2 u2 ) gforth-0.2 “scan”
2024-05-07 03:25:41 <KipIngram   > Consider words like COMPILE that modify the return address.
2024-05-07 03:25:48 <lf94        > Is c-addr2 the same as c-addr1 that's returned?
2024-05-07 03:25:54 <lf94        > nah, cant be
2024-05-07 03:26:04 <lf94        > c-addr2 must be past c-addr1 with u2 being the length until the end
2024-05-07 03:26:05 <KipIngram   > By the time execute did that, fetch probably would have long since used its extracted return address, so now it's forwarded wrong opcodes.
2024-05-07 03:26:56 <KipIngram   > SCAN has consumed the next word, so logically it should have something pointing to the space immediately following the word.
2024-05-07 03:27:04 <KipIngram   > Which will be skipped over by the next SKIP.
2024-05-07 03:27:58 <KipIngram   > c-addre1 would have been the first char in the word - that's where the previous SKIP would have left it.
2024-05-07 03:29:10 <KipIngram   > I assume that the code calling those would have another copy of c-addr1 somewhere, since that's where the word it wants starts.
2024-05-07 03:29:25 <KipIngram   > Then SCAN gives it the end of the word, so it has it bracketed at that point.
2024-05-07 03:29:39 <KipIngram   > But it's been a while - you may need to run some tests to get totally clear on it.
2024-05-07 03:30:34 <KipIngram   > Anyway, this fetch/execute return stack conflict looks like a real problem to me - it seems to really foul up any pipeline I've thought of so far.
2024-05-07 03:30:47 <KipIngram   > Who owns the return stack?  Fetch or execute?
2024-05-07 03:31:32 <KipIngram   > I'd always hoped that since fetch would get a bunch of opcodes on every fetch that it would be able to keep execute wewll-supplied, conditional situations aside.
2024-05-07 03:31:38 <KipIngram   > But this threatens that.
2024-05-07 03:33:00 <KipIngram   > The F18-A caches not only the top of data stack but the top of the return stack as well.
2024-05-07 03:33:25 <KipIngram   > Maybe a way out here is a dedicated instruction for nudging the TOR.  Fetch could recognize that and implement it.
2024-05-07 03:33:57 <KipIngram   > No, that's still problematic isn't it?  Execute might have run >r or r> or something.
2024-05-07 03:34:35 <KipIngram   > I think mixing data and return addresses on the same stack is a problem for this in general.
2024-05-07 03:34:50 <KipIngram   > Fetch really needs to OWN the return stack.
2024-05-07 03:35:20 <KipIngram   > So I'd need something separate for "data juggling."
2024-05-07 03:35:34 <KipIngram   > A "scratch stack."
2024-05-07 03:36:30 <KipIngram   > And then dedicated instructions for any needed adjustments to return address, that fetch would recognize and implement.
2024-05-07 03:38:38 <KipIngram   > lf94: I think given your effects comment on SCAN, if you did this:
2024-05-07 03:38:53 <KipIngram   > DUP SCAN SWAP >IN !
2024-05-07 03:39:31 <KipIngram   > you'd then have c-addr1 u2 on the stack, which would exactly capture the scanned word.
2024-05-07 03:40:03 <KipIngram   > DUP copies c-addr1, SCAN consumes the copy.
2024-05-07 03:40:22 <KipIngram   > Then c-addr2 is the new >IN value after the scanned word is removed.
2024-05-07 03:41:21 <KipIngram   > If I recall right, my TIB is a null-terminated string, but the string returned by WORD is a counted string.
2024-05-07 03:41:38 <KipIngram   > In my system, I mean.
2024-05-07 03:44:05 <KipIngram   > This is my definition of WORD:
2024-05-07 03:44:07 <KipIngram   > : word  wbuf off dup skip scan ;
2024-05-07 03:45:02 <KipIngram   > My SKIP and SCAN use my funky conditional stuff, so I won't throw those at you.
2024-05-07 03:46:00 <KipIngram   > WBUF returns the address where the name string of the next defined word will go.
2024-05-07 03:46:40 <KipIngram   > If I don't happen to be defining a word that later just gets abandoned.
2024-05-07 03:46:52 <KipIngram   > If I am, I fill in the rest of the header around it.
2024-05-07 04:19:22 <lf94        > Today I learned what I expected. String parsing in Forth sucks :D.
2024-05-07 04:19:32 <lf94        > It sucks because there is no good string API.
2024-05-07 04:19:36 <lf94        > I'm going to fix this.
2024-05-07 04:26:18 <lf94        > I'm porting https://gist.github.com/lf94/46d23417b76ad888c095e03f8a2a8cdf and it's amazing how a good string library can go so far.
2024-05-07 04:26:33 <lf94        > My forth code is actually way less verbose than this Zig code, until I get to the string parsing.
2024-05-07 04:29:25 <lf94        > It's the iterator pattern that appears to be very easy to reason about in both Zig and Forth
2024-05-07 04:33:00 <lf94        > I'm not going to let a shitty default string library shake me from using Forth
2024-05-07 04:34:35 <zelgomer    > : word? ( ccc -- 0 | a u -1)  0 [: >r dup bl = or r> ;] scan? ;  : word ( ccc -- a u)  word? ?abort" Unexpected EOF" ;  ( my word def)
2024-05-07 04:39:57 <zelgomer    > well, not quite. some transcription errors. close enough.
2024-05-07 04:42:05 <zelgomer    > i was trying to translate it into something that looks somewhat like conventional forth. the bl = part is really more like [char] ~ 1+ [char] ! within
2024-05-07 04:58:35 <lf94        > these languages have the upper leg because they're creating a temporary state to pull from
2024-05-07 05:02:07 <luiz_       > https://public.websites.umich.edu/~williams/archive/forth/strings/parsing.html ?
2024-05-07 05:10:55 <KipIngram   > lf94: Yep, that's long been one of my complaints about Forth, and I also intend to fix it eventually.
2024-05-07 05:11:21 <KipIngram   > Support for literal data is in general quite limited.
2024-05-07 05:11:37 <KipIngram   > Really only integers, and *maybe* floats.
2024-05-07 05:11:57 <KipIngram   > But lists, arrays, structures in general?  Nah, it's not there.
2024-05-07 16:32:01 <lf94        > I'm going to make forth have one of the nicest string parsing libraries out there.
2024-05-07 16:32:54 <lf94        > zelgomer: what does [: ;] do? it's like some temporary definition?
2024-05-07 16:32:59 <lf94        > inline definition or something
2024-05-07 16:54:26 <crc         > [: ;] is the Forth20xx form of quotations (anonymous definitions, can be used in a word definition)
2024-05-07 16:57:47 <lf94        > yeah, seemed very lambda-esque!
2024-05-07 16:57:56 <lf94        > I feel like this is a thing to avoid maybe
2024-05-07 16:58:04 <lf94        > Are they hard to implement in forth systems?
2024-05-07 16:58:18 <crc         > that'll depend on the system
2024-05-07 16:59:21 <veltas      > Yeah crc must recuse himself on that one ;)
2024-05-07 17:00:08 <crc         > 
ACTION has had them in his systems for over a decade...

2024-05-07 17:00:11 <veltas      > Some forths are very quotation-centric, but in standard forths it is idiosyncratic
2024-05-07 17:00:31 <veltas      > It definitely suits retro nicer than things like gforth
2024-05-07 17:00:36 <veltas      > It also looks nicer in retro
2024-05-07 17:02:32 <veltas      > standard/classic forths
2024-05-07 17:03:00 <lf94        > Are classic forths simpler than retro?
2024-05-07 17:09:21 <crc         > from my experience, in implementing both traditional style and my current ones, I find the overall complexity to be similar
2024-05-07 17:10:00 <veltas      > I think retro is at least as simple or simpler than most 'classic' forths today
2024-05-07 17:10:09 <veltas      > It's probably about as simple as some old ones
2024-05-07 17:10:19 <veltas      > From my uneducated perspective
2024-05-07 17:11:47 <lf94        > Nice :)
2024-05-07 17:12:13 <veltas      > Correct me if I'm wrong but it seems retro's tradeoff is relying on quotations to form all kinds of 'structured' execution
2024-05-07 17:13:16 <veltas      > Inline quotations come with a little overhead but make the control words conceptually simpler, less reliance on magic immediate words etc
2024-05-07 17:14:13 <veltas      > And there's a huge style difference that results too
2024-05-07 17:14:28 <veltas      > I think that's more significant than the implementation / overhead concerns
2024-05-07 17:14:52 <crc         > that tradeoff is correct
2024-05-07 17:41:05 <lf94        > Do you believe quotations should be a core forth fundamental primitive?
2024-05-07 17:41:23 <lf94        > (Your answer means a lot to me.)
2024-05-07 17:41:43 <lf94        > Maybe even take some time to answer this
2024-05-07 17:50:31 <dlowe       > my thought - common lisp has a "readtable" that contains a dispatched function for each character and returns objects.  I can imagine such a thing for forth, where the default reader outputs a steady stream of word tokens, but that can be reconfigured.
2024-05-07 17:52:30 <lf94        > Completely offtopic: my various STM32s came in :) mecrisp-stellaris time.
2024-05-07 18:53:39 <KipIngram   > Fun fun.  :-0
2024-05-07 18:53:43 <KipIngram   > :-), THAT IS.
2024-05-07 18:54:45 <KipIngram   > Re: quotations, I don't know that I think they should be present "out of the box," but I think they make sense for an alternate interpreter that you might load up and use later.  Along with other "types" as well - I view a quotation as a data type that represents code snips.
2024-05-07 18:55:17 <KipIngram   > In the HP-48 line of calculators they support that - there's a particular way you bracket a text string and that causes it to be interpreted as a code segment.
2024-05-07 18:55:27 <KipIngram   > But you can pass it around like data, store it in registers, etc.
2024-05-07 18:55:40 <KipIngram   > It's a first class data type, so to speak.
2024-05-07 19:02:58 <KipIngram   > I don't know how they actually pass it around - it may get passed about as a text string, and the way it's bracketed just tells the system to interpret it as code.  Or it may be some "processed representation."
2024-05-07 19:30:43 <MrMobius    > KipIngram: there are some good interviews available with the designers. That system actually started in the HP-28. Iirc, lists and code like that are identical except for one flag
2024-05-07 19:31:52 <MrMobius    > It doesn't save the text representation. You can indent your code however you like but if stop editing it then reopen it, it will be auto indented and forget all your spaces and new lines
2024-05-07 19:33:01 <MrMobius    > I was digging through the HP48SX ROM recently so it's fresh on my mind :P
2024-05-07 19:47:10 <lf94        > I wish even the clones werent $100+
2024-05-07 19:47:19 <lf94        > These calculators could easily sell for $40
2024-05-07 19:48:35 <thrig       > low demand therefore higher price
2024-05-07 19:50:54 <dbucklin    > I have a handful of 12Cs that I love to use. The SwissMicros versions are pretty nice, too, but I prefer the old HP versions.
2024-05-07 19:54:37 <crc         > imo, quotations are very useful, but the question of their inclusion as a core part of a system really depends on the goals of the system implementer
2024-05-07 19:55:07 <crc         > if you desire a fairly traditional system overall, quotes can feel out of place, and there can be a fair amount of redundancy in functionality
2024-05-07 19:55:18 <crc         > (e.g., you'll have IF/ELSE/THEN, BEGIN/AGAIN, etc, and likely words that use quotations for similar purposes)
2024-05-07 19:58:31 <crc         > if compatibility with traditional forth isn't a goal, then they become more appealing
2024-05-07 19:59:29 <lf94        > it isn't a goal. the addition of quotations should only happen if they are simple to add, and solve a very common pattern
2024-05-07 19:59:45 <lf94        > I think then they can be inclruded as "core"
2024-05-07 19:59:46 <koisoke     > if you are going to have quotations, then the imo straightest-forward thing to is to implement those taking as arguments a condition flag and a quotation, and then implement the more traditional versions as syntactic sugar using whatever your equivalent of reader macros is
2024-05-07 20:00:02 <GeDaMo      > I'd assume that quotations would affect the simplicity of allot
2024-05-07 20:00:26 <lf94        > I would like to see the cases without quotations that are difficult to express.
2024-05-07 20:01:01 <lf94        > Can we simply offer core words that reduce the difficulty? Not necessarily quotation, but just words that handle the extra complexity. No extending forth
2024-05-07 20:01:06 <crc         > My allot is just `:allot &Free v:inc-by ;`
2024-05-07 20:06:02 <GeDaMo      > Hmmm ...  I suppose I meant the way in traditional Forth everything is just appended to the dictionary
2024-05-07 20:08:16 <GeDaMo      > Does a quote just get appended to the dictionary then jumped over like a lit?
2024-05-07 20:09:43 <crc         > yes
2024-05-07 20:10:28 <GeDaMo      > OK :)
2024-05-07 20:35:07 <crc         > I don't have much for comparing code with quotations against traditional forms. https://forth.works/temp/comparison.txt is some excerpts of one of my gopher servers, with retro followed by semi-traditional forms of a few words
2024-05-07 21:06:19 <MrMobius    > lf94: you can get a $40 graphing calculator if you want one. it just won't be RPN or run the loads of software the more expensive ones can
2024-05-07 21:10:07 <lf94        > Ha. Of course I want an RPN. :)
2024-05-07 21:26:02 <dlowe       > build a calculator out of a Scamp
2024-05-07 21:26:49 <dlowe       > wonder how hard it would be, actually. Seems like hooking up the display driver would be the hardest thing.
2024-05-07 21:42:16 <MrMobius    > ive been building calculators as a hobby off and on for about 12 years. the hardware is generally the easiest followed by the software with the keypad being the hardest part
2024-05-07 21:43:59 <dlowe       > what's hard about the keypads?
2024-05-07 21:44:29 <MrMobius    > getting labels with tiny text onto plastic keys that wont wear off
2024-05-07 21:44:51 <MrMobius    > or you can put them on the plastic around the keys if you prefer
2024-05-07 22:00:59 <tbsp        > This makes me wonder what it'd take to repair the handful of buttons in my TI-86 that were damaged by battery leakage
2024-05-07 22:03:02 <MrMobius    > thats too bad. TI-86 is a cool one
2024-05-07 22:04:14 <tbsp        > Yeah. In hindsight I wish I'd bought an HP at the time, but I still quite liked it.
2024-05-07 22:04:20 <lf94        > MrMobius: sell me a cheap HP RPN clone :D
2024-05-07 22:12:49 <tbsp        > Went to dig out my TI-86 and came across a Sharp EL-9600c someone gave me once. Looks like it's RPN :D
2024-05-07 22:20:44 <lf94        > I'll get a RPN I think after I sell a few of these My4th Light boards
2024-05-07 22:20:48 <lf94        > THat'll cover the cost
2024-05-07 22:20:54 <lf94        > I'm going to drown in Forth machines
2024-05-07 22:22:58 <MrMobius    > tbsp: really? I have a 9300C somewhere that is algebraic only
2024-05-07 22:35:45 <tbsp        > MrMobius: Yeah, you're right. I was throw off by the big "ENTER" button (instead of =)
2024-05-07 22:37:45 <MrMobius    > hehe
2024-05-07 22:44:15 <tbsp        > (I'm trying really hard to not buy another calculator right now)
2024-05-07 22:53:57 <KipIngram   > dbucklin: I use a SwissMicros DM42, and it's very nice, but I also preferred the mechanical design of the older HPs.  41 era - the keyboard was an absolute joy.
2024-05-07 22:54:33 <KipIngram   > HP used to be a fantastic company.
2024-05-07 23:00:05 <KipIngram   > I try to make a point to use it anytime I have an excuse, even though other ways might be easier.  Just to uphold tradition.
2024-05-07 23:40:49 <zelgomer    > re: quotations earlier -- i tend to write callback-heavy c. e.g., for iterating data structures, instead of a each_foo() { } macro like you might see in linux, i usually write an each_foo(foo, func, arg) iterator function. i view quotations as the most natural way to migrate this style to forth.