2022-02-19 01:14:48 <remexre     > >r is a bad idea at the interpreter prompt, if the interpreter is written in forth
2022-02-19 06:18:36 <veltas      > joe9: It's not allowed by standard FORTH, if you want to use >R just put it in a colon def, or anonymous colon def
2022-02-19 06:19:10 <veltas      > I mean put the balanced return stack work in a colon def, not just >R
2022-02-19 06:19:29 <joe9        > veltas, yes, that is what I am noticing too.
2022-02-19 06:19:37 <joe9        > just wanted to check if it is normal behaviour.
2022-02-19 06:20:06 <joe9        > what do you think of another stack (other than the parameter or return stacks)?
2022-02-19 06:20:16 <veltas      > Dictionary is a bit like another stack
2022-02-19 06:20:17 <joe9        > do you use more than 2 stacks?
2022-02-19 06:20:32 <joe9        > yes, you can say that.
2022-02-19 06:20:42 <veltas      > Some people use another stack so they can do something like ALLOT in words that might be compiling or writing to dictionary
2022-02-19 06:21:28 <joe9        > the exception handler stack is used in eforth (and f83?)
2022-02-19 06:21:29 <dave0       > i did the dictionary as a stack and the code came out pretty nice
2022-02-19 06:21:32 <veltas      > For instance someone in here puts PAD at the end of the dictionary memory space, and they have -PAD +PAD to add or subtract 256 bytes to that like a 'stack'
2022-02-19 06:22:05 <joe9        > dave0, you mean have the dictionary link pointers as a stack?
2022-02-19 06:22:16 <veltas      > joe9: Exception handler stack like a wordlist can be embedded among dictionary defs
2022-02-19 06:22:22 <dave0       > joe9: yep, instead of a linked list
2022-02-19 06:22:41 <veltas      > Or actually maybe it's embedded in return stack?
2022-02-19 06:22:50 <veltas      > Sorry I am sick as a dog today lol
2022-02-19 06:22:58 <dave0       > joe9: it was basically an array of pointers to execution tokens
2022-02-19 06:22:58 <veltas      > Got the flu or something
2022-02-19 06:23:09 <joe9        > dave0, would you mind sharing more thoughts on the "the code came out pretty nice"?
2022-02-19 06:24:05 <veltas      > The only problem with having lots of separate stacks is it's arguably wasteful, but with virtual memory maybe not, or a simple forth like sectorFORTH
2022-02-19 06:24:13 <joe9        > I like the idea of PAD as I come up with needing different pad spaces simultaneously.
2022-02-19 06:25:11 <veltas      > Well I personally am considering not using PAD but instead having something called SCRATCH that does the same thing without touching PAD
2022-02-19 06:25:29 <joe9        > veltas, why?
2022-02-19 06:25:51 <veltas      > Because I don't want to allow complicated bugs to form from misuse of PAD
2022-02-19 06:25:58 <dave0       > joe9: okay sure.. i had the variable `last` point to the top of the dictionary, but when i create a word, i write the address of the word to the next free spot in the dioctionary, but i don't update last until the end of the definition with semicolon
2022-02-19 06:26:18 <veltas      > I think it's a safe principle that no words should affect PAD, or at the very least no words that touch the dictionary
2022-02-19 06:26:23 <joe9        > ok, that is the smudge/reveal bit
2022-02-19 06:26:27 <joe9        > in the len byte.
2022-02-19 06:27:00 <dave0       > joe9: semicolon comes out very simple like    -2 last +!    (the dictionary grows downwards like the data and return stacks)
2022-02-19 06:27:03 <veltas      > Well it's an alternative to smudge
2022-02-19 06:27:25 <veltas      > I did it dave0's way in zenv and probably will again in my current FORTH projcet
2022-02-19 06:27:55 <dave0       > veltas: yeah i think it is quite elegant
2022-02-19 06:28:16 <veltas      > And maybe a 127 character name is useful
2022-02-19 06:28:37 <dave0       > maybe if your words are in chinese :-p
2022-02-19 06:28:45 <dave0       > and utf-8
2022-02-19 06:28:51 <veltas      > Hmmm
2022-02-19 06:28:55 <veltas      > I mean 'yes'
2022-02-19 06:28:58 <veltas      > If you implement wordlists as hash tables then you should allow longer names like that so I can use your wordlists as maps :P
2022-02-19 06:29:32 <veltas      > Well, that's a 'map' in lisp anyway, even without a hash table
2022-02-19 06:31:50 <joe9        > if that is the only reason for the dictionary stack, why not use a temporary variable to hold that pointer till the ;?
2022-02-19 06:32:13 <dave0       > joe9: you can reuse `last` for that
2022-02-19 06:32:29 <joe9        > yes, something like that.
2022-02-19 06:32:44 <veltas      > I didn't use a dictionary stack to do this
2022-02-19 06:33:32 <joe9        > if the 127 character names is being an issue, it seems simpler to just use cell lengths over byte lengths.
2022-02-19 06:33:35 <dave0       > joe9: for colon, to add to the dictionary, it was like     here last 2 - !    and for semicolon   last @ 2 - last !    remember that `last` always points to the top of the dictionary
2022-02-19 06:33:55 <veltas      > joe9: That's a waste of bytes though
2022-02-19 06:34:00 <veltas      > Think of the environment
2022-02-19 06:34:10 <veltas      > Computing environment
2022-02-19 06:35:14 <veltas      > We're all computing conservationists here
2022-02-19 06:35:46 <veltas      > I list my age on Twitter as the size of Windows in-memory when I was born
2022-02-19 06:36:56 <veltas      > No joke though I think there is a point about energy waste and the 'culture' of computing today
2022-02-19 06:37:29 <joe9        > watch out for premature optimization. your time is more precious than computing power these days.
2022-02-19 06:37:37 <joe9        > yolo.
2022-02-19 06:38:03 <veltas      > Yes but it's not premature optimization to decide not to make something unnecessarily large
2022-02-19 06:38:34 <veltas      > And it's not premature optimization to decide on a humbler set of environment support to write a program, although I admit FORTH is pushing it a bit
2022-02-19 06:38:49 <veltas      > But we're here because we enjoy it
2022-02-19 07:57:14 <iyzsong     > do we have any forth based CAD, like openscad or cadquery?
2022-02-19 11:32:24 <veltas      > iyzsong: I don't think so, better get started
2022-02-19 11:32:34 <veltas      > There actually might be, I wouldn't know
2022-02-19 13:12:00 <KipIngram   > I think one of the reasons we don't see more tools of that sort is that most programmers have a huge separation between "their tools" and "their result."  They seek to take the tools and "build an application environment."  Forth kind of asks you to take a different approach - Forth wants to *be* your application environment, that you've created just by implementing a suitable "application lexicon."  So if a
2022-02-19 13:12:03 <KipIngram   > client comes to you with ideas already in place about how the user interface should work and things like that, you're somewhat beaten before you start.  You can still do that using Forth, but it's not really the way Forth wants to be used.
2022-02-19 13:12:44 <KipIngram   > Producing that solution is probably going to wind up requiring more code than producing a "Forth oriented solution."
2022-02-19 13:13:40 <KipIngram   > Forth wants to be "part of the solution" in ways that other languages don't.
2022-02-19 13:25:34 <KipIngram   > One facet of that problem is that most clients in software projects have already decided they want a GUI-based solution, even if the application at hand doesn't really require one.
2022-02-19 13:25:45 <KipIngram   > Because that's just "how software is supposed to be" in their eyes.
2022-02-19 13:26:58 <KipIngram   > Forth *already gives you* a user interface, and it *already gives you* a scripting language, and so on - right out of the box.  But you're rarely allowed to capitalize on those things if there's a "client in charge."
2022-02-19 13:35:23 <MrMobius    > heh, so would you really allow the average client access to the forth interpreter if they were open to command line stuff?
2022-02-19 13:36:15 <KipIngram   > Well, remember that you can restrict the available words however you like - you don't have to give them access to the whole dictionary.  Though of course if you don't you taking away a lot of the "scripting" capability.
2022-02-19 13:36:30 <KipIngram   > But it's easy enough to arrange things so that the application words are all they can use.
2022-02-19 13:40:20 <MrMobius    > can you remove the primitives too?
2022-02-19 13:47:41 <KipIngram   > Sure, if you've arranged your dictionary right.  The general idea would be to build all of your application words in a particular vocabulary, and then restrict the word search to that vocabulary and no others - Vocabulary FORTH would be excluded too.
2022-02-19 13:47:51 <KipIngram   > I don't know that all Forths allow that, but the ones I write do.
2022-02-19 13:50:01 <KipIngram   > I have, at any given time, a linked list of vocabularies that the thing will search looking for your word.  There are other reasons you want to have a lot of control over that too.  Maybe you're cross-compiling, and you want to compile a definition of a word for your target.  It needs to search target word vocabularies, and not search host word vocabularies.
2022-02-19 13:50:45 <KipIngram   > In that case you'd leave yourself a "way out" that would re-instate the proper host environment.  But for a kiosk-style application you'd want a hard barrier that couldn't be broken.
2022-02-19 13:59:09 <KipIngram   > Or if you're trying to make your system able to recompile itself - if it's steaming through a "new build" definition and comes to !, you want it to find the ! that's in your new build target - not the ! in your currently running system.
2022-02-19 13:59:49 <KipIngram   > In that case all that really matters is that you come to the right version first, but I'd probably have the entire dictionary of the "running system" walled off during that phase.
2022-02-19 14:19:35 <joe9        > KipIngram: are the forths you have written hosted somewhere?
2022-02-19 14:20:40 <KipIngram   > No, I haven't really circulated them.  The only one I wouldn't be ashamed of is my latest one, and it's not "done" yet.  I'll probably share it at some point.
2022-02-19 14:21:13 <KipIngram   > One of them was a gnu c implementation - it worked rather well, and I was happy with "how" it worked, but the source code was a monstrosity.
2022-02-19 14:21:25 <KipIngram   > The last couple of iterations have used nasm.
2022-02-19 14:21:49 <KipIngram   > And no C library - just four or five OS syscalls, and the rest native.
2022-02-19 14:22:28 <joe9        > you'd want a hard barrier that couldn't be broken. -- I would like to see how this works in practice.
2022-02-19 14:22:40 <KipIngram   > One of the first problems you run into is that the way most OS syscalls for reading from the keyboard don't work in a way that is good for Forth - you make the syscall, and you don't get control back until the user hits Enter.
2022-02-19 14:22:42 <joe9        > I understand how it works.
2022-02-19 14:22:50 <joe9        > just curious of how it is implemented.
2022-02-19 14:23:41 <KipIngram   > Well, the key is in the way you decide what vocabularies to search.  I've done it two ways - in one I used a "stack" of vocabularies. A physical array, into which I put pointers to vocabularies.
2022-02-19 14:23:50 <joe9        > and you don't get control back until the user hits Enter. -- I have been thinking about how to avoid such blocking calls too.
2022-02-19 14:23:54 <KipIngram   > This most recent time I've implemented that by including link fields in the vocabulary words.
2022-02-19 14:24:06 <KipIngram   > You have to change a bunch of termios.
2022-02-19 14:25:54 <KipIngram   > You have to change C_IFLAGS, C_LFLAGS, C_CC[VTIME], and C_CC[VMIN].
2022-02-19 14:26:07 <KipIngram   > And if you're being graceful you need to save the originals and put them back anytime you're exiting.
2022-02-19 14:26:50 <KipIngram   > If you want me to I can dig the numerical details (for Linux) out of my code later and post it.
2022-02-19 14:27:00 <KipIngram   > I.e., what to set each one to.
2022-02-19 14:27:43 <joe9        > I am more interested in the implementation of the vocabularies and how you implemented the stack of vocabularies.
2022-02-19 14:27:59 <KipIngram   > Anyway, what this latest system does is has CONTEXT point to the first vocabulary to search - that one points to the next one, and so on until you come to one with a link field of 0.
2022-02-19 14:28:08 <KipIngram   > FIND iterates through that.
2022-02-19 14:28:10 <joe9        > regarding the termios stuff, I am not doing this on linux/unix. So, it might not be relevant to me.
2022-02-19 14:28:27 <KipIngram   > One implementation ago I actually had CONTEXT be an array.
2022-02-19 14:28:44 <joe9        > with your forth's, is there a forth that you started off branching from? such as fig, f83, etc..
2022-02-19 14:28:46 <KipIngram   > And I'd start at the 0th entry, search that, go to the 1st entry, search that, and so on.  Again until a zero entry.
2022-02-19 14:29:21 <KipIngram   > My stuff is mostly based on that McCabe book, Forth Fundamentals voume 1.  Which I think is mostly based on FIG.
2022-02-19 14:30:01 <KipIngram   > The main thing I've changed is that instead of having word bodies immediately follow the header, I separate the headers to another part of  memory and include in each one a pointer to the appropriate body.
2022-02-19 14:30:10 <KipIngram   > Makes it easy to replace an existing definition, for one thing.
2022-02-19 14:30:34 <joe9        > why would you want to replace a definition?
2022-02-19 14:30:40 <KipIngram   > It re-uses the same header - just points to a new definition.
2022-02-19 14:30:53 <KipIngram   > Well, you don't, very often.  But sometimes it's an interesting thing to be able to do.
2022-02-19 14:31:00 <KipIngram   > Kind of esoteric corner cases, mostly.
2022-02-19 14:31:08 <joe9        > just curious of the use case for that.
2022-02-19 14:31:27 <KipIngram   > Well, the main reason I did it was because I wanted to be able to "execute through" from one word to another, if I chose to.
2022-02-19 14:31:29 <KipIngram   > Like this:
2022-02-19 14:31:43 <KipIngram   > : foo ...code... : bar ...more code... ;
2022-02-19 14:31:47 <joe9        > i like f83 as it keeps the complexity down avoiding the create/does demarcation.
2022-02-19 14:31:52 <joe9        > and doing that with different words.
2022-02-19 14:31:57 <KipIngram   > If the header for bar has to be right before the body, that doesn't work very well.
2022-02-19 14:32:08 <KipIngram   > But the way I have it set up, foo just executes right through into bar.
2022-02-19 14:32:17 <KipIngram   > The two headers just point into the code at the right places.
2022-02-19 14:32:43 <joe9        > like assembly.
2022-02-19 14:32:50 <KipIngram   > create/does is a tedious thing to implement, particularly if you want to use direct threading.
2022-02-19 14:32:55 <KipIngram   > it's a bit cleaner with indirect threading.
2022-02-19 14:33:09 <KipIngram   > 
ACTION likes assembly too.

2022-02-19 14:34:12 <KipIngram   > The other reason you might want to separate headers would be if you were trying to deal with a tethered system, where the headers were on the host and the bodies on the target.
2022-02-19 14:34:17 <KipIngram   > I've never done one of those.
2022-02-19 14:34:34 <KipIngram   > But an IRC friend was always interested in such things, and our conversations led me to think about how to do it.
2022-02-19 14:34:52 <KipIngram   > He was interested in very tiny targets - the smallest little microcontrollers.
2022-02-19 14:35:01 <KipIngram   > Where there was no way to have a full system on the target.
2022-02-19 14:35:15 <KipIngram   > My own embedded system interests run toward... more capable targets.
2022-02-19 14:35:33 <KipIngram   > Like maybe an instrument, like an oscilloscope or something.
2022-02-19 14:35:44 <KipIngram   > I'd make sure I had plenty of resources on such a target.
2022-02-19 14:36:07 <joe9        > makes sense for such scenarios.
2022-02-19 14:36:08 <KipIngram   > I'd probably have the whole Forth living over there, and just serial into it.
2022-02-19 14:36:30 <KipIngram   > But I still might want to be able to do things like recompile the target OS and send a new version over.
2022-02-19 14:36:43 <KipIngram   > Mix host and target words in various ways, for testing and so on.
2022-02-19 14:36:57 <KipIngram   > So how to organize such things is an interesting topic for me.
2022-02-19 14:37:43 <KipIngram   > What I keep hoping is that eventually I'll port this Linux  Forth, with its 4-5 syscalls, to some sort of bare metal project, which will involve actually implementing the things those syscalls do.
2022-02-19 14:38:54 <KipIngram   > Those are mostly 1) KEY, 2) EMIT, 3) BLOCK-READ, 4) BLOCK-WRITE.  Then the termios syscalls, but I wouldn't need those on a bare metal thing.
2022-02-19 14:40:58 <joe9        > any ideas on how you are managing input streams? just put them on the stack while switching?
2022-02-19 14:45:47 <KipIngram   > That's a thorny part.  I'd really love to have something as powerful as the approach Linux brings, where you can pipe i/o from one command to another and so on.  I've given that thought, but I really don't have a solution I'm fully happy with yet.
2022-02-19 14:46:08 <KipIngram   > "Basic Forth" just doesn't work that way.
2022-02-19 14:47:14 <KipIngram   > Some kind of a level of indirection is needed, I guess - a word you're executing is going to use KEY to get its input.  You'd need to wrap that in some sort of "execution content" that instructed the system on what to do with KEY calls from that word.
2022-02-19 14:47:26 <joe9        > KipIngram: any opinions on f83 or eforth?
2022-02-19 14:47:31 <KipIngram   > Currently my KEY just goes straight for the OS read syscall.
2022-02-19 14:48:18 <KipIngram   > None on eforth - I've never used it.  I've only used F83 a little.  Most of my "formal" knowledge of stuff out there is related to FIG and to Forth79.
2022-02-19 14:48:28 <joe9        > I have to rush out now. I will be back later. Thanks again.
2022-02-19 14:48:37 <KipIngram   > I've used pforth in consulting projects a long time ago.
2022-02-19 14:48:45 <KipIngram   > Stay safe.
2022-02-19 14:48:47 <joe9        > How about polyforth?
2022-02-19 14:48:51 <joe9        > thanks.
2022-02-19 14:49:01 <KipIngram   > No, haven't used that one either.  I've mostly written my own.  :-)
2022-02-19 14:52:36 <joe9        > what do you think of the exception stack?
2022-02-19 14:53:07 <joe9        > exception handling stack
2022-02-19 14:53:53 <MrMobius    > mecrisp is pretty cool if youre interested in tethered forths
2022-02-19 14:54:48 <KipIngram   > I have sort of a sledge hammer approach to errors.  Before I begin processing each line of input (i.e., each QUERY), I snapshot more or less my entire system.  Not something that would be feasible on an embedded system, but with all my GB of RAM on a PC, I figure why not?  I mean a literal RAM snapshot, of everything.
2022-02-19 14:54:51 <MrMobius    > theres also a really interesting thing where you use the debug interface on the chip to execute stuff so you dont need a second microcontroller between host and target
2022-02-19 14:54:54 <KipIngram   > Then I start processing.
2022-02-19 14:55:01 <KipIngram   > If I make it to the end of the line with no error, great.
2022-02-19 14:55:23 <KipIngram   > But if an error occurs, I just drop through a trap door so to speak, into code that re-instates that snapshot and drops me into the outer interpreter.
2022-02-19 14:55:45 <KipIngram   > I.e., restores me to the beginning of the line, before I ever typed that input.
2022-02-19 14:55:58 <KipIngram   > It's fairly bullet-proof error recovery.
2022-02-19 14:56:23 <KipIngram   > And I have a command history implemented, so I can just hit the up-arrow key to get back that problematic line of input, edit it, and try again.
2022-02-19 14:56:39 <KipIngram   > In other words, on exceptions I ENTIRELY BAIL.
2022-02-19 14:57:18 <KipIngram   > I don't do any handling of actual "runtime" exceptions currently.
2022-02-19 14:57:25 <KipIngram   > I know what I want to do, though.
2022-02-19 14:57:42 <KipIngram   > I want to hook the OS bit that handles segfaults and so on, and do some sort of recovery.
2022-02-19 14:57:58 <KipIngram   > If I divide by zero, or try to read invalid memory, I crash.
2022-02-19 14:57:59 <joe9        > f83 / eforth use a stack of exception handlers to jump to.
2022-02-19 14:58:18 <KipIngram   > I'd prefer to handle that more gracefully - it would restore the same image I restore on compile errors.
2022-02-19 14:59:25 <vms14       > KipIngram: there is no way to avoid saving a backup every time?
2022-02-19 14:59:36 <vms14       > it's interesting by the way
2022-02-19 14:59:57 <vms14       > you just set backpoints and come back if something bad happened
2022-02-19 14:59:58 <KipIngram   > Well, when I first began that path, I saved less.  But I just kept finding new ways to foul the system up that I wasn't covering (Forth basically lets you do anything).
2022-02-19 15:00:04 <vms14       > so you don't loose integrity
2022-02-19 15:00:10 <KipIngram   > So I eventually got tired of that and just said "screw it - I'm saving it all."
2022-02-19 15:00:18 <vms14       > haha
2022-02-19 15:00:27 <KipIngram   > I did try to "pick away" at things for a little while, but I eventually gave up.
2022-02-19 15:01:00 <KipIngram   > Particulrly when you start defining and switching around among vocabularies, there are pretty suble ways to fuck things up.
2022-02-19 15:01:03 <vms14       > what about a sandboxed approach?
2022-02-19 15:01:10 <vms14       > would be more efficient or even worse?
2022-02-19 15:01:30 <KipIngram   > yeah, I'm not sure.  It's sort of the reverse of what I'm doing.
2022-02-19 15:01:44 <KipIngram   > If you sandbox, and things go RIGHT, then you need to recover the new state from the sandbox, right?
2022-02-19 15:01:53 <vms14       > it's a great idea, but it's expensive
2022-02-19 15:01:59 <KipIngram   > I haven't tried it that way; my guess is it's similar in expense.
2022-02-19 15:02:04 <MrMobius    > could the interpreted version of each primitive save what it's about to overwrite to a buffer so you can replay and restore only what was changed?
2022-02-19 15:02:12 <KipIngram   > Yes, it is - but that's where the fact that I'm running on this massively powerful PC comes in.
2022-02-19 15:02:21 <KipIngram   > "I can afford it."  Right now, at least.
2022-02-19 15:02:30 <KipIngram   > I don't think it would port to a more limited system very well.
2022-02-19 15:03:09 <KipIngram   > But a nice thing about it is that if my stack is in a certain state, and I type a bad line that executes 2/3 of the way through before failing, I get my original stack back - totally painlessly.
2022-02-19 15:03:19 <vms14       > KipIngram: actually it's nice that you use the resources you have in the machine so you do stuff you wouldn't in most cases
2022-02-19 15:03:21 <KipIngram   > I don't have to "figure out" how to recover from my mess up.
2022-02-19 15:03:26 <vms14       > it lets you innovate
2022-02-19 15:03:44 <vms14       > and once you master the idea then you can simplify it
2022-02-19 15:03:45 <KipIngram   > Yeah, my goal has sort of been to create the smoothest possible "me experience."
2022-02-19 15:04:00 <vms14       > KipIngram: develop for you, not for others
2022-02-19 15:04:23 <vms14       > I mean, usually the products that had some value were because a guy needed something and did x thing
2022-02-19 15:04:36 <KipIngram   > I've totally taken that to heart.  I'm not really a software professional - I'm a hardware guy.  But I've picked up enough software over the years to be dangerous.  What I haven't ever done is program in a collaborative way.
2022-02-19 15:04:37 <vms14       > but he did it for himself, and ended being useful for others too
2022-02-19 15:04:42 <KipIngram   > So it's always been "for me."
2022-02-19 15:05:25 <vms14       > KipIngram: collaborative work in forth seems much harder than most other languages
2022-02-19 15:06:07 <KipIngram   > And when I go to work I have to put up with all the annoyances of "existing in a corporate world" - my Forth work is where I get to do precisely what I want to, and answer to no one.
2022-02-19 15:06:10 <vms14       > cause the language is something kind of abstract that takes form by the way, so every programmer has it's own language and methods
2022-02-19 15:06:32 <vms14       > this is why java "shines" in job market
2022-02-19 15:06:48 <vms14       > cause it's so restrictive that it's likely all devs will do the stuff in the same way
2022-02-19 15:07:17 <MrMobius    > ya you can unplug one programmer and just plug in some other one. same for C in embedded
2022-02-19 15:07:19 <KipIngram   > Forth is at the opposite extreme - you can really do almost anything you please, and it's happy to cooperate with you.
2022-02-19 15:07:59 <KipIngram   > It appeals to my "individualistic" nature.
2022-02-19 15:08:29 <vms14       > I've just started to learn forth, so I don't really understand the language. But I like what I see
2022-02-19 15:08:30 <KipIngram   > Heh.  "Forth as a political statement."
2022-02-19 15:08:31 <KipIngram   > :-)
2022-02-19 15:08:51 <KipIngram   > Thinking Forth by Brodie is great, if you haven't glommed onto it yet.
2022-02-19 15:08:52 <vms14       > it resonates with my way to do stuff
2022-02-19 15:09:10 <vms14       > KipIngram: a guy in telegram recommended me this book several times
2022-02-19 15:09:13 <KipIngram   > Whereas that McCabe book is "under the hood," TF is more about the "philosophy of using  Forth."
2022-02-19 15:09:22 <KipIngram   > Together the two of them are a great Forth education.
2022-02-19 15:09:52 <KipIngram   > There are other books - Starting Forth gets recommended a lot.
2022-02-19 15:10:06 <KipIngram   > But McCabe and Brodie - that's really a powerhouse combination.
2022-02-19 15:10:17 <vms14       > I always asked him about metaprogramming and bottom up and he somehow always ended mentioning  forth and the book
2022-02-19 15:10:44 <KipIngram   > :-)  That's what happens to us Forth heads.  It winds up altering us psychologically or something.
2022-02-19 15:11:01 <KipIngram   > I saw a comment once by a guy that said learning Forth had changed how he designed hardware too.
2022-02-19 15:11:17 <KipIngram   > It's the emphasis on modularity, I think.  The whole "factor, factor, factor" dictate.
2022-02-19 15:11:26 <vms14       > KipIngram: what about you, aren't you a hardware guy?
2022-02-19 15:11:30 <KipIngram   > I've gotten almost obsessed with short defintions over the years.
2022-02-19 15:11:43 <vms14       > did forth change the way you design/think about hardware?
2022-02-19 15:11:51 <KipIngram   > Yes, I am a hardware guy.  But I wouldn't say that Forth has changed how I do hardware.
2022-02-19 15:12:14 <KipIngram   > At least not the way it did for him - he said he's moved toward building little "sub-modules" that he could then plug together to get higher stuff done.
2022-02-19 15:12:18 <KipIngram   > Like "hardware words."
2022-02-19 15:12:26 <vms14       > lol
2022-02-19 15:12:35 <veltas      > KipIngram: "but the source code was a monstrosity" nothing wrong with that
2022-02-19 15:12:42 <KipIngram   > If you give me an embedded project, I'm still probably going to think about one circuit board.
2022-02-19 15:13:16 <KipIngram   > I really enjoy embedded, though, because I get to make decisions about the hardware and the software, how they work together, and so on.
2022-02-19 15:13:22 <vms14       > KipIngram: actually pluggable hardware is a nice idea
2022-02-19 15:13:35 <KipIngram   > Throwing up that "wall" between hardware and software teams has never made a lot of sense to me.
2022-02-19 15:13:50 <vms14       > even more if they're kind of a forth word, in the sense that we don't have to care what's in there
2022-02-19 15:13:51 <KipIngram   > I think they need to know one another's worlds at least to some extent to get the best outcome.
2022-02-19 15:14:16 <KipIngram   > These days I tend to write definitions that are no more than 40-50 characters long.
2022-02-19 15:14:29 <veltas      > FORTH has changed how I write C a little, it's made me better I think. Understanding better when to use static storage duration etc, how to refactor more
2022-02-19 15:14:38 <KipIngram   > I use the classic "64 character line" in my block editors, and I HATE multi-line definitions.
2022-02-19 15:14:43 <veltas      > vms14: Is there a telegram FORTH group?
2022-02-19 15:14:59 <vms14       > veltas: idk I think I've escaped from telegram
2022-02-19 15:15:02 <KipIngram   > I just shudder when I see a "block" of Forth that is all indented and covers half the screen like a C function would.
2022-02-19 15:15:05 <vms14       > but there should be
2022-02-19 15:15:11 <vms14       > maybe dead ones
2022-02-19 15:15:40 <veltas      > To each their own KipIngram
2022-02-19 15:15:56 <KipIngram   > You bet - that's also a Forth-ism.
2022-02-19 15:15:58 <vms14       > forth is kind of unknown so it's hard to see the community
2022-02-19 15:16:04 <KipIngram   > It's a big world - we all can do it how we like.
2022-02-19 15:16:21 <vms14       > even this irc channel is kind of empty
2022-02-19 15:16:24 <veltas      > I'm interested to know how you'd factor certain things, mostly I find loops make me not want to over-factor
2022-02-19 15:16:36 <veltas      > I'll send something for you to refactor sometime lol
2022-02-19 15:16:53 <KipIngram   > This channel had a big hiccup when the whole server fiasco hit a year ago or so.
2022-02-19 15:17:11 <vms14       > but I think it's more about the fact forth is strongly related with assembly and running with no system
2022-02-19 15:17:11 <veltas      > Drama spreads like fire
2022-02-19 15:17:28 <KipIngram   > Yes - Forth is happier if it's the only game in town.
2022-02-19 15:17:30 <vms14       > if there was focus on web development it would be more known
2022-02-19 15:17:43 <vms14       > the last web stuff in forth I see is java applets
2022-02-19 15:17:54 <vms14       > without counting all the js forth implementations
2022-02-19 15:17:57 <remexre     > isn't web stuff mostly string processing?
2022-02-19 15:18:13 <vms14       > remexre: depends if you want js or not
2022-02-19 15:18:27 <vms14       > a web application is not string processing
2022-02-19 15:18:29 <KipIngram   > String processing in Forth is definitely something that needs some work.
2022-02-19 15:18:40 <KipIngram   > If I have to munge a bunch of random text around, I reach for Python.
2022-02-19 15:18:47 <vms14       > it's users, db, auth, input, ouptut, templates, etc
2022-02-19 15:18:49 <veltas      > A good web forth would be javascript-based, 'web assembly' is literally more complicated IMO
2022-02-19 15:19:05 <vms14       > veltas: I saw waforth
2022-02-19 15:19:22 <vms14       > but meh
2022-02-19 15:19:51 <lagash      > veltas: it's not JS based?? it's pure WASM..
2022-02-19 15:19:59 <vms14       > actually you can interoperate js to wasm
2022-02-19 15:20:03 <veltas      > I suppose it depends what you want, in my opinion the strengths of FORTH are: portability (mostly for embedded), and simplicity
2022-02-19 15:20:05 <remexre     > vms14: most db interfaces, the io you'd be doing, and templates are all in terms of strings though, yeah?
2022-02-19 15:20:11 <vms14       > well wasm is a module loaded in js
2022-02-19 15:20:23 <veltas      > lagash: I didn't meantion waforth, someone else did
2022-02-19 15:20:33 <lagash      > you can run WASM outside of a browser
2022-02-19 15:20:37 <vms14       > remexre: yes, but I mean, there is a need to provide those libraries
2022-02-19 15:20:39 <veltas      > Two 'v' names, I know it's confusing lol
2022-02-19 15:20:44 <vms14       > it's not just output an html file
2022-02-19 15:20:46 <veltas      > You can run JS outside of a browser :P
2022-02-19 15:20:58 <vms14       > actually it's all text processing
2022-02-19 15:21:03 <lagash      > yeah but if you're not using Deno, I doubt that's too good of an idea :P
2022-02-19 15:21:03 <vms14       > and some numbers
2022-02-19 15:21:29 <veltas      > You can run Z80 outside a browser, but if I'm writing a FORTH to run in a web browser I'll work with dirty simple javascript
2022-02-19 15:22:10 <siraben     > https://github.com/siraben/ti84-forth can be loaded onto https://www.cemetech.net/projects/jstified/ and ran
2022-02-19 15:22:13 <vms14       > veltas: when you're done give me a minified.js that I can use please
2022-02-19 15:22:21 <siraben     > sort of in browser, but it's because it's a Z80 emulator
2022-02-19 15:22:41 <veltas      > I have actually given this some thought, and I'll say this because I do every time the subject comes up: a web browser is today's VT100
2022-02-19 15:23:04 <vms14       > what do you mean about it's today's vt100
2022-02-19 15:23:06 <veltas      > A good web forth needs a backend + frontend approach, comprehensive solutions to your forthy web stack needs
2022-02-19 15:23:18 <vms14       > you mean is the "common" interface of users?
2022-02-19 15:23:48 <veltas      > In many ways, I mean a vt100 was the 'terminal' most people had, and now a web browser is the common terminal people use to interact with computers
2022-02-19 15:23:52 <vms14       > veltas: yes, but with js you can make single page applications, and you have some power
2022-02-19 15:24:03 <veltas      > Most people's actual *computer* is just a dumb terminal for accessing websites
2022-02-19 15:24:24 <vms14       > the only drawback is it won't run in text browsers
2022-02-19 15:24:45 <vms14       > I wanted to care about them, but you literally can't use them
2022-02-19 15:25:02 <vms14       > most of pages won't display
2022-02-19 15:25:08 <veltas      > The VT100 had big text and small text, later variations had colors and flashing. The web is what we use for that now, as well as marquee
2022-02-19 15:25:16 <veltas      > And a couple other things have been added since then
2022-02-19 15:25:29 <veltas      > JavaScript is just very sophisticated flashing text
2022-02-19 15:25:31 <vms14       > if it's all js you can create buttons and put a callback on them
2022-02-19 15:25:52 <vms14       > if it's backend it becomes harder
2022-02-19 15:25:54 <veltas      > Yeah I know you can actually do a lot with javascript, and I don't have anything against that, I'm just joking
2022-02-19 15:26:09 <vms14       > well you shouldn't take db stuff
2022-02-19 15:26:14 <vms14       > but a json will do
2022-02-19 15:26:32 <veltas      > Nope it should send data as FORTH
2022-02-19 15:26:34 <veltas      > Or binary
2022-02-19 15:26:39 <veltas      > In my humble opinion
2022-02-19 15:26:40 <remexre     > thought the all-backend way got a lot easier if you do defunctionalized continuations
2022-02-19 15:27:05 <remexre     > which tbh might be easier with forth-on-the-backend than C/JS/Python-on-the-backend
2022-02-19 15:27:26 <vms14       > but why there is no forth on the backend?
2022-02-19 15:27:36 <veltas      > There is
2022-02-19 15:27:41 <vms14       > the only option seems to be gforth + bindings
2022-02-19 15:27:43 <veltas      > There's a website run by forth somewhere
2022-02-19 15:28:06 <veltas      > Most 'desktop forths' allow binding to C libraries
2022-02-19 15:28:08 <remexre     > forth doesn't excel at string processing, and lots of the application areas where forth excels don't super-duper care about web interfaces?
2022-02-19 15:28:39 <vms14       > veltas: I was amused when I saw how easy is in gforth
2022-02-19 15:28:46 <veltas      > I think FORTH doesn't 'excel' at anything in particular, but I've found it capable at strings etc when it needs to be
2022-02-19 15:28:50 <veltas      > With the right words
2022-02-19 15:28:59 <vms14       > https://rosettacode.org/wiki/Draw_a_pixel#Forth
2022-02-19 15:29:10 <lagash      > siraben: oh! thought I recognized your handle! yeah I've used your ti84-forth on real hardware :)
2022-02-19 15:29:14 <veltas      > vms14: I'm hoping to make it relatively easy in my FORTH
2022-02-19 15:29:23 <lagash      > in fact I was considering coding some more in it recently
2022-02-19 15:29:33 <vms14       > give me a forth
2022-02-19 15:30:02 <vms14       > I want a forth to make a game
2022-02-19 15:30:20 <vms14       > and another for web dev
2022-02-19 15:30:42 <veltas      > Use gforth or any
2022-02-19 15:30:47 <vms14       > actually I should try to compile gforrth
2022-02-19 15:30:53 <veltas      > Yep you should
2022-02-19 15:30:54 <vms14       > and start trying to bind stuff
2022-02-19 15:31:13 <vms14       > it seems to be like what I'm asking for
2022-02-19 15:31:13 <veltas      > Mine is going to be standard FORTH so you can switch if you want later
2022-02-19 15:31:26 <vms14       > I have pforth
2022-02-19 15:31:31 <veltas      > Cool
2022-02-19 15:32:40 <veltas      > FORTH code is actually extremely portable, because even with totally different dialects you can 'port' all the different words to a new environment
2022-02-19 15:33:04 <veltas      > Just numbers that aren't portable, unless the FORTH you port to has recognizers
2022-02-19 15:34:13 <remexre     > 20 CONSTANT $14  :)
2022-02-19 15:34:22 <veltas      > lol
2022-02-19 15:35:01 <vms14       > I saw save-forth saves the variables values
2022-02-19 15:35:12 <vms14       > but won't save memory allocated not?
2022-02-19 15:35:14 <KipIngram   > I made mine accept numbers in any radix.
2022-02-19 15:35:44 <KipIngram   > b:10000 x:10 16 16:10 all are the same number.
2022-02-19 15:35:59 <KipIngram   > x: and b: are special cases; otherwise it's just <radix>:<digits>.
2022-02-19 15:36:08 <KipIngram   > Works all the way up to base 62.
2022-02-19 15:36:31 <KipIngram   > letters are case insensitive until you get to base 36 or 37 - wherever you need A and a to be different.
2022-02-19 15:36:41 <KipIngram   > Digits are 0-9 A-Z a-z
2022-02-19 15:38:00 <KipIngram   > I haven't implemented numeric output this latest round yet, but last go round I had the usual . and then also supported a "C style" format string kind of thing.
2022-02-19 15:38:26 <remexre     > huh, I might adopt that next time I futz with parse-number; last time I touched it, I added ^ for octal and ~ for invert
2022-02-19 15:38:44 <siraben     > lagash: hehe, nice!
2022-02-19 15:38:58 <KipIngram   > A friend recommended the <base>: syntax; I decided I liked it.
2022-02-19 15:39:07 <remexre     > but 8:755 def seems more readable, yeah
2022-02-19 15:39:42 <KipIngram   > Anyway, any approach that gets rid of having BASE as a global variable is good, in my opinion.
2022-02-19 15:40:51 <vms14       > please make : :D cr ." :D" cr ; as a builtin in your forths
2022-02-19 15:41:08 <remexre     > do you have a base-parametric . then, KipIngram ?
2022-02-19 15:42:07 <KipIngram   > Right - haven't written . yet this time, but that is an issue.  That syntax above is great for number *input*.
2022-02-19 15:42:14 <KipIngram   > But you still have to know what to do for output.
2022-02-19 15:42:48 <KipIngram   > I haven't thought of anything better than "assuming 10 but having some way to override."  Last time . used 10 and nothing else, and I used formatted output to do other bases.
2022-02-19 15:43:14 <KipIngram   > Formatted output was like TYPE, except if it saw a "format string" in the string it was outputing it would use it and a stack parameter to write a number.
2022-02-19 15:43:22 <KipIngram   > And I can specify the desired base in the format string.
2022-02-19 15:43:44 <KipIngram   > But that's not implemented yet on my latest.
2022-02-19 15:44:18 <remexre     > hm, I was considering just having like, $U. ^U. #. etc
2022-02-19 15:44:28 <KipIngram   > I was churning along really well on it about 10 months ago, using my work-issue Macbook Air.  But last summer I bought a Linux notebook - my first personally owned computer in like 10 years.
2022-02-19 15:44:41 <remexre     > for all bases {#,$,%,^}, signed or unsigned {,U}, and space after or not {,N}
2022-02-19 15:44:43 <KipIngram   > I ported it over - got the termios squared away and so on - and then have hardly touched it since.
2022-02-19 15:44:47 <KipIngram   > I really need to get back to it.
2022-02-19 15:45:03 <KipIngram   > It's sitting there in my Dropbox folder waiting for me.
2022-02-19 15:47:16 <KipIngram   > I did those format strings by making a little byte code interpreter - it "executes" the format string.  A stack cell is treated as a "stack of bytes" that that little vm works on.
2022-02-19 15:47:47 <KipIngram   > A plus of having a 64-bit platform; eight bytes in that cell makes a "stack" big enough to do something with.
2022-02-19 15:48:51 <lagash      > what about a 128-bit platform? :O
2022-02-19 15:48:58 <KipIngram   > Anyway, the formatted output word consumes the stack cell that pointed to the string, but additionally consumes one more stack cell for each number that it output.  So you can do a b c <format string> printf and all four parameter cells are removed by printf.
2022-02-19 15:49:10 <KipIngram   > :-)  Even better, I guess.
2022-02-19 15:49:20 <KipIngram   > Though eight is enough to handle the formatted output task.
2022-02-19 15:50:16 <veltas      > remexre: What's the point of unsigned prefix?
2022-02-19 15:50:32 <veltas      > Oh for printing out, that's right
2022-02-19 15:51:30 <remexre     > yeah, in the past I had it be "signed iff decimal," but that always felt like a hack
2022-02-19 15:52:03 <veltas      > I have record format for no space (just pass 0), and a zero-padding for unsigned numbers
2022-02-19 15:52:47 <KipIngram   > Yeah - that byte code interpreter recognizes 'u'.
2022-02-19 15:53:01 <veltas      > And you have to plunge your hands into the filth and use BASE/DECIMAL/HEX to change the base
2022-02-19 15:53:11 <KipIngram   > And <base>: and the width, number of decimal points, etc.
2022-02-19 15:53:26 <KipIngram   > All of them small numbers that a byte can hold.
2022-02-19 15:53:38 <veltas      > Okay what's the point of recognizing u?
2022-02-19 15:53:48 <KipIngram   > To print the number unsigned.
2022-02-19 15:54:11 <veltas      > Oh you said 'interpreter' I thought you meant interpreting numbers
2022-02-19 15:54:22 <veltas      > Not interpreting number printing functions
2022-02-19 15:54:30 <KipIngram   > There's a little baby byte code interpreter in printf that processes the format field characters.
2022-02-19 15:55:05 <KipIngram   > Most of the time it just prints the string character to the screen, like TYPE.  But if it comes to a format field it hands off to the byte code interpreter instead.
2022-02-19 15:55:53 <KipIngram   > It will figure out how to show that next number and print it, then return to the main TYPE loop.
2022-02-19 15:56:49 <KipIngram   > And joe9 was asking earlier about streams - yeah, that's a good question.  It would be nice to be able to easily redirect screen output into a block or something like that.
2022-02-19 15:57:06 <KipIngram   > I've pondered that but haven't yet arrived at anything I really love.
2022-02-19 15:57:36 <KipIngram   > It's just the kind of thing Linux excels at, and I'd like for Forth to excel at it too.
2022-02-19 15:57:40 <KipIngram   > Same for string processing.
2022-02-19 15:58:02 <KipIngram   > Being able to pop a bunch of Linux commands into a pipeline is just a really powerful thing.
2022-02-19 15:58:47 <KipIngram   > Taking strings apart into pieces, like Python's <string>.split("<c>") - same thing.  Very powerful.
2022-02-19 15:59:12 <KipIngram   > I want to eventually marry these things into Forth in some clean way.
2022-02-19 15:59:44 <KipIngram   > A year, year and  half ago we talked in here about Lisp for few days.  It prompted me to go dig into Lisp a bit, and I decided it's almost as easy to implement as Forth is.
2022-02-19 16:00:05 <KipIngram   > I've given serious thought to having a "Lisp memory zone" alongside my Forth memory map and allowing the two to interact.
2022-02-19 16:00:25 <remexre     > yeah, my current forth is pretty much explicitly for this
2022-02-19 16:00:37 <remexre     > for various high-level GC'd languages, not just Lisp
2022-02-19 16:00:42 <KipIngram   > I don't see any good way to truly "merge" them - they have very different philosophies of memory management, for example.  But I think they could usefully exist "side by side."
2022-02-19 16:02:08 <KipIngram   > So that's another way to potentially take advantage of "all that RAM" we have on our PCs.
2022-02-19 16:02:57 <KipIngram   > Lisp also appears to have a "following" that's almost as culty as our  Forth community is - that kind of "enthusiasm" is appealing to me.  :-)
2022-02-19 16:03:19 <KipIngram   > I figure they can't be *completely* wrong - there must be something good going on over there.
2022-02-19 16:04:51 <remexre     > I don't know what's up with Scheme people, but CL's OOP capabilities are both excellent in both theory and practice IME (I work at a CL company), and very unforthy in philosophy :)
2022-02-19 16:05:42 <vms14       > remexre: :O (he works in a cl company wtf)
2022-02-19 16:06:14 <vms14       > no wonder why you were in lispcafe
2022-02-19 16:06:39 <KipIngram   > Yeah - they're very different mindsets from what I can tell.  That's why I was a little surprised at how simple Lisp looks under the hood.  It just didn't look like it would be that hard to build to me.
2022-02-19 16:06:54 <vms14       > remexre: how is to work in a cl company instead of the others?
2022-02-19 16:06:59 <vms14       > there's really a difference?
2022-02-19 16:07:04 <KipIngram   > But... I've not yet *done it*, so maybe I shouldn't comment too strongly.
2022-02-19 16:07:22 <vms14       > would you prefer a forth based one?
2022-02-19 16:07:32 <KipIngram   > My sense is that Lisp attracts a much more "formal computer science" sort of mind set.
2022-02-19 16:07:58 <remexre     > KipIngram: yeah, the very most core parts of a CL implementation are pretty simple (other than GC, I guess?), but the standard library in the ANSI spec is huge by comparison, and MOP is really tricky to implement right
2022-02-19 16:08:03 <KipIngram   > Whereas in all honestly I think us Forthwrights are kind of "hacky" in many cases.
2022-02-19 16:08:34 <KipIngram   > Well, even the mark and release GC algo looked fairly simple, at leats to my first reading.
2022-02-19 16:08:58 <remexre     > vms14: it's really nice, but I don't think that's as much because of the language as because we're a small company
2022-02-19 16:09:06 <KipIngram   > Having all of the memory pool blocks being one common size - that helps enormously.
2022-02-19 16:09:37 <KipIngram   > My last Forth had ground floor fixed page size dynamic memory.
2022-02-19 16:09:49 <remexre     > KipIngram: yeah like, a basic GC isn't hard in an "absolute sense," just hard compared to implementing Forth :)
2022-02-19 16:09:53 <KipIngram   > This time around I decided to forego that, though - it was enticing me down a feature creep road that I didn't like.
2022-02-19 16:10:30 <KipIngram   > The main reason I started over was because things in that direction had started to get a little murky.
2022-02-19 16:10:33 <remexre     > also, vectors, strings, and structs mean you don't get to have a fixed allocation size, though having a separate allocator + pool of memory for cons cells is a good idea regardless
2022-02-19 16:11:06 <KipIngram   > Yeah - I think you can do all those things with fixed size cells, but not very efficiently.
2022-02-19 16:11:20 <KipIngram   > Like I've seen reference to numbers being represented as one cell per digit.
2022-02-19 16:11:34 <KipIngram   > So that's basically support for bignum.  But it's not at all efficient.
2022-02-19 16:11:37 <remexre     > that feels a bit turing-tarpitty lol
2022-02-19 16:11:43 <KipIngram   > Exactly.
2022-02-19 16:12:27 <KipIngram   > Eventually I want a Forth that can do things like Octave and Matlab - scientific computing.  With natural support for vectors, matrices, tensors, etc.
2022-02-19 16:12:45 <KipIngram   > But that's getting pretty complex for a Forth, and it's not something I'd try to support "from the ground floor."
2022-02-19 16:13:03 <KipIngram   > I'd come at that by implementing a replacement outer interpreter, that added the extra capabilities.
2022-02-19 16:13:14 <KipIngram   > Run it when I wanted it, then exit back to the native OI.
2022-02-19 16:13:46 <KipIngram   > That fancy OI would keep up with the types of the stack items, provide some kind of dynamic memory management, etc.
2022-02-19 16:14:20 <KipIngram   > And it would use the types at the top of the stack to guide word searches, so + on a pair of matrices would run different code from + on a pair of integers.
2022-02-19 16:14:45 <KipIngram   > But the overhead of implementing all of that would be compile time - once your app words were compiled they'd "just run" the way Forth words always do.
2022-02-19 16:15:11 <KipIngram   > I think to do it you'd need fields in the header to indicate what kind of stuff the word expected on the stack.
2022-02-19 16:15:23 <KipIngram   > And also describing how the word LEFT the stack.
2022-02-19 16:16:02 <remexre     > maybe do refcounting and make DUP increment the refcount?
2022-02-19 16:16:07 <KipIngram   > So the first puzzle to solve would be "How do I PREPARE for those capabilities without hopelessly bloating the ground-floor system?"
2022-02-19 16:16:29 <KipIngram   > Might just be one "extension cell" in the header, that would usually be null, but could be used for other things later.
2022-02-19 16:16:49 <KipIngram   > The native outer interpreter would never even look at that cell.
2022-02-19 16:17:10 <KipIngram   > But it could "point to" all kinds of interesting information that fancy extensions could use.
2022-02-19 16:18:05 <remexre     > it feels to me like this could be a wordlist tbh though
2022-02-19 16:18:30 <KipIngram   > Yeah, could be.  But I might want to type something like
2022-02-19 16:18:37 <KipIngram   > A B * 17 *
2022-02-19 16:18:41 <KipIngram   > where A and B are matrices.
2022-02-19 16:18:48 <KipIngram   > Those are *different* *'s.
2022-02-19 16:18:48 <remexre     > * would be in the wordlist
2022-02-19 16:18:58 <KipIngram   > And they're both in one line.
2022-02-19 16:19:05 <remexre     > though wait nvm right scalars exist
2022-02-19 16:19:23 <KipIngram   > And of course we could do
2022-02-19 16:19:24 <remexre     > was going to say "and then just have a vtable on vectors and matrices"
2022-02-19 16:19:34 <KipIngram   > A B MM* 17 MS*
2022-02-19 16:19:43 <KipIngram   > But that would be the sort of thing I was trying to avoid.
2022-02-19 16:20:04 <KipIngram   > I'm sure Charles Moore would tell me that last is exactly what I should do.
2022-02-19 16:20:21 <KipIngram   > Though he'd probably have some clever way of avoiding the matrices altogether.
2022-02-19 16:20:42 <remexre     > yeah, agree that that sucks; if you're fine boxing scalars I'd still say a way involving dynamic type-tests would be fine+fast enough
2022-02-19 16:21:17 <KipIngram   > And A and B are just bit patterns on the stack - you'd have to have some way of knowing they're meant to indicate matrices.
2022-02-19 16:21:33 <KipIngram   > If you want to have overloaded operators, at least.
2022-02-19 16:21:37 <remexre     > they're pointers no matter what, yeah?
2022-02-19 16:21:48 <remexre     > A CELL - @  gives you a type tag
2022-02-19 16:21:57 <remexre     > * branches on the type tag
2022-02-19 16:22:13 <KipIngram   > Oh, ok - you're saying have ONLY pointers on the stack.
2022-02-19 16:22:16 <KipIngram   > yeah, that could work.
2022-02-19 16:22:35 <KipIngram   > But my thoughts around this have been around having all the overhead be at compile time and none at runtime.
2022-02-19 16:22:42 <KipIngram   > I want runtime to rip snort.
2022-02-19 16:22:49 <veltas      > Sounds like you're slowly converging on a high-level scripting language
2022-02-19 16:23:23 <veltas      > What were you using matrices for?
2022-02-19 16:23:24 <KipIngram   > I think so to, but as an "additional layer."  I don't think any of this stuff has a place in the first interpreter running when you start up your Forth.
2022-02-19 16:23:26 <remexre     > for numerical stuff, I thought the SOTA was "gluing together operations can be slow, the thing that'll make it really fast is fusing your matrix ops together"
2022-02-19 16:24:02 <KipIngram   > It's been a long time since I've thought much about this in particular.
2022-02-19 16:24:53 <veltas      > If I was doing stuff with vectors/matrices I'd consider having wordlists for their ops
2022-02-19 16:24:57 <remexre     > I'm also natively a compilers person, not a numerical person, so my opinions here should be taken with a grain of salt lmao
2022-02-19 16:25:16 <veltas      > So I could use +-*/ etc without any 'cleverness'
2022-02-19 20:58:31 <joe9        > : build ( 'string nstring 'cs -- 'cs ) \ build a counted string at 'cs from 'string
2022-02-19 20:58:40 <joe9        > is there a better name than build for this word?
2022-02-19 21:04:32 <joe9        > tocs is too cryptic
2022-02-19 21:04:38 <joe9        > to_counted_string is too long.
2022-02-19 21:05:23 <joe9        > it is the inverse of count
2022-02-19 21:05:31 <joe9        > and I think some forth had a word for that.
2022-02-19 21:09:54 <joe9        > pack$ of eforth.
2022-02-19 21:19:06 <joe9        > and place of f83