2024-10-28 00:10:54 <zelgomer    > thinking of abandoning vocabularies and search order
2024-10-28 00:11:06 <zelgomer    > maybe, i'm not sure yet
2024-10-28 02:08:47 <xentrac     > zelgomer: it's going to be pretty tough for you to do a metacompiler without some kind of vocabulary system
2024-10-28 02:55:27 <zelgomer    > true
2024-10-28 02:55:33 <zelgomer    > probably
2024-10-28 12:16:49 <xentrac     > https://forth-standard.org/standard/alpha is back up
2024-10-28 12:17:12 <xentrac     > and so is https://gforth.org/manual/Integrating-Gforth.html
2024-10-28 16:31:20 <user51      > xentrac: I keep running into you on CAN  :) this time https://news.ycombinator.com/item?id=32218329
2024-10-28 16:31:20 <user51      > xentrac: I had more to say, but after reading and thinking a bit I realized I shouldn't have an opinion.
2024-10-28 17:10:53 <xentrac     > user51: haha
2024-10-28 17:11:11 <xentrac     > hey, I called out neauoire's uxn there
2024-10-28 20:05:37 <veltas      > Working on a static object Forth, written in assembly first for AMD64/psABI/ELF, with a focus on C interop
2024-10-28 20:06:16 <veltas      > The aim is to have an .so you can link and embed in a C program, or just run standalone as a relocatable Forth environment that interops with your system C libraries better
2024-10-28 20:07:21 <veltas      > Other attempts I've had at x86 Forth haven't really taken C interop seriously, but interop with C is extremely desirable for a hosted Forth
2024-10-28 20:07:57 <veltas      > And if I'm interested in writing a standalone Forth or x86 OS then interop with C is a good step 1 on that long road
2024-10-28 20:08:50 <veltas      > I'd like to do a portable C implementation as the next platform so I immediately get 'all' the platforms, and can worry about assembly versions when I can be bothered to put the performance legwork in
2024-10-28 20:09:24 <veltas      > But AMD64 I'm doing first because I want to understand the dynamic relocations and linking properly, and because I find it easier to write Forths in assembly
2024-10-28 20:14:44 <veltas      > shared* object
2024-10-28 21:39:54 <veltas      > zelgomer: wordlists are a trivial feature, just having multiple chains in dictionary, and quite useful.  The problem in my opinion is making it feel 'forthy'
2024-10-28 21:40:04 <veltas      > The standard's fallen short on that
2024-10-28 21:41:07 <amby        > i mean logically you want the ability to include a wordlist for a) the next word or b) all words until you exclude it again
2024-10-28 21:41:45 <amby        > (also for convenience i will refer to a wordlist as a "module" cuz that's how i refer to similar things in my head)
2024-10-28 21:42:02 <amby        > for example you'd go "MOD-NAME MEMBER" to use MEMBER once
2024-10-28 21:42:15 <amby        > or MODIN MOD-NAME if you wanted to use it a lot in a block of text
2024-10-28 21:42:40 <xentrac     > using
2024-10-28 21:43:00 <amby        > what's the antonym for using
2024-10-28 21:43:07 <veltas      > My module library declares a word that replaces the top wordlist in search order, so you could do:  MOD-NAME MEMBER FORTH  to just do one word
2024-10-28 21:43:09 <amby        > because for MODIN it's MODOUT
2024-10-28 21:43:10 <xentrac     > abusing
2024-10-28 21:43:55 <amby        > the other advantage of that is you can use modules to define struct fields
2024-10-28 21:44:18 <GeDaMo      > 'without' ?
2024-10-28 21:44:30 <amby        > WITH/WITHOUT could work
2024-10-28 21:44:58 <amby        > now i'm thinking of how to implement it
2024-10-28 21:45:39 <zelgomer    > it just hit me. i think i might be happier if i just make a word that sets definitions back to what it was before the start of parsing the current file.
2024-10-28 21:45:45 <amby        > you could have like. multiple LATESTs
2024-10-28 21:46:19 <amby        > zelgomer: like FORGET but just for LATEST and not HERE?
2024-10-28 21:46:32 <veltas      > Like PREVIOUS
2024-10-28 21:46:57 <zelgomer    > previous only changes the search order, not the current definitions target
2024-10-28 21:47:07 <veltas      > Right
2024-10-28 21:47:12 <veltas      > END-MODULE is what I call it :P
2024-10-28 21:48:05 <zelgomer    > i don't want to end-module though. i want to be able to define some private words and then switch and define some public words. when i write c, i usually intermix static functions and extern functions, grouping things by relevance rather than by scope
2024-10-28 21:48:42 <veltas      > I use PUBLIC and PRIVATE for that
2024-10-28 21:49:01 <zelgomer    > i know, i was trying to avoid having special purpose words just for this use case
2024-10-28 21:49:18 <amby        > isn't that kinda forth's thing?
2024-10-28 21:49:32 <zelgomer    > anyway, since you fuckers made me think about it again, i think i know how i will do it
2024-10-28 21:49:38 <veltas      > Cool
2024-10-28 21:49:50 <veltas      > Well that's why I live rent-free in your head :P
2024-10-28 21:50:54 <xentrac     > haha awesome
2024-10-28 21:51:07 <xentrac     > fancy brackets are underused ﴾ ﴿
2024-10-28 21:51:53 <xentrac     > {- -} [{ }] [# #]
2024-10-28 21:51:57 <GeDaMo      > «»
2024-10-28 21:52:17 <thrig       > <o=> oh no tie bombers
2024-10-28 21:52:21 <zelgomer    > when i wrote that the other day, i was already thinking about changing the words around to be more "forthy". e.g., "also" doesn't dup the top of context, and "forth" doesn't replace the TOS with itself. instead, i was going to change it around so forth is just a variable and "also" consumes TOS and pushes it to context. i saw another forth somewhere on github doing this, i think it's better. e.g., "only
2024-10-28 21:52:27 <zelgomer    > also foo definitions" becomes  "forth only  foo also  foo definitions"  it's a little wordier maybe, but then when i can do is have a special vocabulary that refers to the definitions vocab when the file start parsing. maybe i'll call it public, idk.
2024-10-28 21:53:12 <zelgomer    > the big thing, at least for the style i've been using, is that "definitions" referencing the top of context is really clumsy
2024-10-28 21:53:29 <zelgomer    > being able to say "public definitions" at any time without dicking around with the context will be nice
2024-10-28 21:54:17 <veltas      > I think before ANS you would do  <wordlist> CURRENT !  or something like that
2024-10-28 21:54:52 <amby        > you can do whatever you want
2024-10-28 21:54:57 <amby        > that's the nice thing about forth
2024-10-28 21:55:29 <zelgomer    > every pre-ans forth i've seen used the model where the execution of <wordlist> didn't push it to the param stack, but replaced the top of context
2024-10-28 21:55:57 <veltas      > Which makes for nicer application usage
2024-10-28 21:56:40 <veltas      > I'm pretty sure I've seen CURRENT but could be wrong
2024-10-28 21:56:49 <zelgomer    > does it though? it's strange behavior, and only in service of being able to write "also stuff" instead of "stuff also"
2024-10-28 21:57:04 <veltas      > e.g. FORTH and EDITOR
2024-10-28 21:57:14 <veltas      > It's the 'normal' behavior
2024-10-28 22:59:18 <veltas      > zelgomer, how about this?  Two words, SNIP and VOCAB.  SNIP word1 word2  removes word1 thru word2 from the dictionary chain so they can't be found anymore.  VOCAB name word1 word2  does same but makes a word to replace LATEST with the removed chain
2024-10-28 23:01:21 <veltas      > And don't bother with CURRENT at all, don't have any distinction between the search and definition chains