2023-10-03 06:10:12 <rendar      > historically, had Forth some form of command to repeat the last word for N times again? or, you can do that only with the LOOP word?
2023-10-03 06:22:41 <GeDaMo      > Traditionally, it would be something using the looping constructs
2023-10-03 06:22:53 <GeDaMo      > But you can always write your own looping word
2023-10-03 06:23:52 <GeDaMo      > https://forth.sourceforge.net/standard/dpans/dpansa3.htm#A.3.2.3.2
2023-10-03 06:27:52 <veltas      > I've seen a lot of stuff like TIMES that just does an xt multiple times
2023-10-03 06:28:32 <rendar      > hmm interesting
2023-10-03 06:30:30 <veltas      > Not hard to implement  : TIMES ( ... n xt - ...)  BEGIN OVER WHILE 2>R R@ EXECUTE 2R> SWAP 1- SWAP REPEAT 2DROP ;
2023-10-03 06:30:36 <veltas      > Something like that anyway
2023-10-03 06:31:24 <veltas      > Untested :)
2023-10-03 06:43:14 <rendar      > veltas, why those R> words to modify return stack?
2023-10-03 06:44:52 <veltas      > rendar: To leave n and xt out of the way so the word being executed can modify the data stack if it needs to
2023-10-03 06:45:05 <rendar      > oh
2023-10-03 06:45:14 <veltas      > i.e. 10 ' DUP TIMES will leave 11 10's on the stack
2023-10-03 06:45:16 <veltas      > In theory
2023-10-03 06:45:20 <rendar      > that's too advanced for me, for now
2023-10-03 06:45:23 <veltas      > i.e. 10 10 ' DUP TIMES will leave 11 10's on the stack
2023-10-03 06:45:26 <veltas      > I mean
2023-10-03 06:45:32 <veltas      > I've not tested it
2023-10-03 06:46:55 <veltas      > I'll sprinkle my standard "learn the basics before trying to write a forth" advise on this conversation
2023-10-03 06:47:03 <veltas      > advice*
2023-10-03 06:47:20 <GeDaMo      > Another way you could do it is with an immediate word which actually calls to the target word into the word being currently compiled
2023-10-03 06:47:43 <GeDaMo      > That's not necessarily a good idea :P
2023-10-03 11:57:59 <KipIngram   > rendar: Just to make it clear to you, >r and r> can only be used in a definition.
2023-10-03 11:58:06 <KipIngram   > You can't run them interactively.
2023-10-03 11:58:14 <KipIngram   > it's an excellent way to crash your system.
2023-10-03 11:58:14 <rendar      > oh! thanks for that
2023-10-03 11:58:39 <KipIngram   > This is of course because the interpreter is interpreting your code - it made some call and left a return address on the return stack.
2023-10-03 11:58:49 <KipIngram   > If your >r or r> gets executed then, it's hosed.
2023-10-03 11:59:01 <KipIngram   > It just executes the word you specified - it doesn't know what it's going to do.
2023-10-03 11:59:35 <KipIngram   > In a definition you just have to take care of yourself, and make sure that when you come to the return point the return stack has a good address waiting.
2023-10-03 11:59:52 <KipIngram   > Basically that means that r> and >r should be "balanced" in a definition.
2023-10-03 12:00:04 <KipIngram   > Unless you're deliberately trying to hack the control flow.
2023-10-03 12:00:17 <KipIngram   > For example:
2023-10-03 12:00:29 <KipIngram   > : foo  r> drop ;
2023-10-03 12:00:43 <KipIngram   > That won't return to foo's caller - it will return to the caller of foo.
2023-10-03 12:01:09 <KipIngram   > I have a set of "conditional double return" words that play that sort of game.
2023-10-03 12:02:34 <KipIngram   > The flip side of this is that Forth's "system code" can't go leaving things on the data stack behind the scenes.  During interpretation, the user owns the data stack and the system owns the return stack.
2023-10-03 12:02:57 <KipIngram   > In compile mode, though, the system DOES sometimes use the data stack to save information for later use.
2023-10-03 12:03:09 <KipIngram   > For example, IF compiles a conditional jump, but it doesn't know where to jump to yet.
2023-10-03 12:03:17 <KipIngram   > That's somewhere out ahead in the source stream.
2023-10-03 12:03:36 <KipIngram   > So it leaves the address of the spot in memory that needs to get that target stored in it on the stack.
2023-10-03 12:03:48 <KipIngram   > Later on, THEN scoops that address up and patches the right target into it.
2023-10-03 12:04:10 <KipIngram   > But it's ok for IF to dirty up the stack, because you aren't "executing" - you're compiling.
2023-10-03 12:13:54 <KipIngram   > Hey guys, I heard that that uiua language introduced a bunch of "beyond APL" symbols in order to handle the fuzziness in an RPN language about how many arguments to take from the stack (monadic vs. dyadic).
2023-10-03 12:14:07 <KipIngram   > That would make it a lot harder for an APL person to transition to, I think.
2023-10-03 12:14:33 <KipIngram   > It occurred to me that a Chuck-style trick could user color to make that distinction, and then one's "symbol memory" could come ovre intact.
2023-10-03 12:14:41 <KipIngram   > s/ovre/over/
2023-10-03 12:20:58 <KipIngram   > Anyway, it would have all the same difficulties that colorForth had, in terms of sharing source code and so forth, but another issue I had with colorForth is that there were too many colors - at the font size I normally use it wasn't always easy to distinguish them "painlessly."
2023-10-03 12:21:15 <KipIngram   > in this case the colors would see much more limited use and I imagine that problem would be mitigated.
2023-10-03 12:22:30 <crc         > colorforth does make use of a large text size
2023-10-03 12:23:56 <GeDaMo      > Chuck has a degenerative eye condition which is the reason for the big font and the colours
2023-10-03 12:44:20 <KipIngram   > crc: Yes, but in my tinkering with colors I didn't want to.  And it just doesn't work as well at the smaller font sizes.
2023-10-03 12:44:30 <KipIngram   > I've seen pictures of Chuck's screens.  :-)
2023-10-03 12:45:16 <KipIngram   > I used to use 10-point fonts for my consoles, but these days I've had to accept 12, and it won't surprise me if I'm at 13 in a few years.
2023-10-03 12:45:49 <KipIngram   > Anyway, that would completely solve the monadic/dyadic uncertainty.
2023-10-03 12:46:17 <KipIngram   > But so would a single prefix character, so...
2023-10-03 13:50:34 <KipIngram   > Just to the bottom of a bug in my system.
2023-10-03 13:50:57 <KipIngram   > I have my prefix method for specifying numeric base on input, but I have BASE for output.
2023-10-03 13:51:24 <KipIngram   > I noticed a while back that if I set BASE to 16, then my EXPECT goes funky on me once I get to the tenth character of the line.
2023-10-03 13:51:34 <KipIngram   > Doesn't crash, but the cursor starts jumpin around.
2023-10-03 13:51:56 <KipIngram   > Well, it's because I use ANSI sequences in there to move the cursor around, and some of those involve outputing text digits.
2023-10-03 13:52:33 <KipIngram   > So I'm going to have to find the right places to save and restore BASE.  And this is exactly the problem with having that kind of global variable in the first place.
2023-10-03 14:29:09 <veltas      > Interesting bug
2023-10-03 14:34:44 <gordonjcp   > fun!
2023-10-03 14:35:41 <gordonjcp   > would it be easier to wrap . or just have two copies?
2023-10-03 15:18:43 <KipIngram   > Yeah, I was thinking that just finding a way to avoid the global altogether would really be the best thing to do.
2023-10-03 15:19:30 <KipIngram   > But the fastest thing to do would be to just add a word that prints decimal numbers, regardless of what BASE is.
2023-10-03 16:20:55 <veltas      > Globals are fine when they're not leaked all over your program
2023-10-03 16:21:09 <veltas      > But BASE is everywhere so it can get tricky
2023-10-03 16:21:20 <veltas      > I suppose it's not usually a problem so you can see why it was left that way
2023-10-03 16:22:16 <thrig       > still a rake to step on
2023-10-03 16:36:03 <KipIngram   > Yeah.  What would be better here, I think is to have separate base values for "the system" and "the user."  The problem here was that as a user I changed BASE, and that affected things the system tried to do, just in the course of normal operations.
2023-10-03 16:36:55 <KipIngram   > Of course implementing that would make sharing code between the system and the user harder.
2023-10-03 16:37:13 <KipIngram   > Well, maybe not.  BASE is really supposed to be a user variable.
2023-10-03 16:37:32 <KipIngram   > So if the application and the system showed up as different users that would get it.
2023-10-03 16:37:54 <KipIngram   > I just don't have my system set up that way.
2023-10-03 16:37:57 <KipIngram   > Maybe next time.
2023-10-03 16:38:49 <KipIngram   > For the next system I anticipate having a dedicated thread that manages the physical console, so it ought to be easy for it to have its own variable set.
2023-10-03 16:41:44 <KipIngram   > I figure that thread will use move data to/from the real console, and will distribute it out to other threads based on which one owns the console at that time.
2023-10-03 16:42:09 <KipIngram   > And that thread will have 10 in its BASE variable.
2023-10-03 23:50:20 <seepel      > 
ACTION Hi ##forth! I'm going through the exercise of building a simple ITC Forth following JonesForth and Moving Forth. In JonesForth there is mention of dictionary entries having a back pointer so that it is easier to disassemble them. It seems like if you re-arranged the dictionary structure you wouldn't need a back pointer. Here is a diagram of what I'm thinking, is this a bad idea? https://paste.debian.net/1293954/

2023-10-03 23:55:21 <KipIngram   > seepel: That looks close to a standard dictionary to me.  I am more familiar with older Forth structures than newer ones, though.
2023-10-03 23:55:35 <KipIngram   > In a typical system you might find support for "vocabularies."
2023-10-03 23:55:45 <KipIngram   > Each vocabulary is an independent list of words.
2023-10-03 23:56:06 <KipIngram   > So in the actual vocabulary implementation field, you have a pointer to the latest defined word in that vocabulary.
2023-10-03 23:56:17 <KipIngram   > And then each word points back to word defined just before it.
2023-10-03 23:56:23 <KipIngram   > That's for each vocabulary.
2023-10-03 23:56:39 <KipIngram   > These vocabulary words are themselves in some vocabulary so that you can find them to start your search process.
2023-10-03 23:57:02 <KipIngram   > Usually at any time you have a list of vocabularies that are used for word searches, and a single vocabulary that new word definitions will go into.
2023-10-03 23:57:21 <KipIngram   > The variable CONTEXT is often used to point to the search list.
2023-10-03 23:57:42 <KipIngram   > So CONTEXT points to a list of vocabularies, each vocabulary points to its latest word, and each word to its predecessor.
2023-10-03 23:58:04 <KipIngram   > Note that you don't necessarily have all vocabularies present in the CONTEXT list - just the ones you've chosen for use at that time.
2023-10-03 23:58:18 <KipIngram   > The vocabulary receiving new definitions is indicated by a variable called CURRENT.
2023-10-03 23:58:26 <KipIngram   > There can only be one of those at any given time.
2023-10-03 23:58:30 <KipIngram   > Does that make sense?
2023-10-03 23:58:44 <KipIngram   > Oh, I'm sorry - I misread your diagram.
2023-10-03 23:58:56 <KipIngram   > It's the JonesForth diagram that looks typical.  Let me look at yours for a moment.
2023-10-03 23:59:10 <KipIngram   > You diagram look fine too - for a single vocabulary.
2023-10-03 23:59:34 <KipIngram   > I think it makes more sense to put the link before the name string, but that can be done in a lot of ways.