2024-07-02 10:34:42 I have a link in my mind between Forth and Adobe. Can anyone give me a reference please? 2024-07-02 10:37:54 it's a tenuous link, but it might be that adobe invented postscript, and postscript is similar to forth (concative and stack base) 2024-07-02 10:38:38 https://en.wikipedia.org/wiki/PostScript 2024-07-02 10:48:27 Yes, thanks. I followed up my question here with ChatGpt and got the same response. The founders of PostScript were Forth programmers. 2024-07-02 10:49:05 You were faster than the AI today! 2024-07-02 10:55:25 lol 2024-07-02 11:16:00 skvery: I'll see what I can find. I do think there are some connections out there between Forth and various sorts of "document presentation" things. Postscript has some similarities too, and iirc so does Apple's font management stuff. 2024-07-02 11:16:44 Ah, I see dave0 was also onto the postscript connection. 2024-07-02 11:16:54 :-) 2024-07-02 11:17:01 hay KipIngram 2024-07-02 11:17:25 At some point in time I found a big docuentation site on the Apple stuff, and I want to think I saw Forth looking stuff in that. 2024-07-02 11:17:30 Hi dave0. 2024-07-02 13:53:15 skvery> Yes, thanks. I followed up my question here with ChatGpt and got the same response. The founders of PostScript were Forth programmers. 2024-07-02 13:53:34 i thought i read that they have dubiously denied this 2024-07-02 14:09:46 KipIngram: TTF or OTF, one of those I think has a stack-based VM 2024-07-02 14:09:57 Can't remember why, maybe to specify font hinting 2024-07-02 14:10:30 https://developer.apple.com/fonts/TrueType-Reference-Manual/RM05/Chap5.html 2024-07-02 14:10:39 https://developer.apple.com/fonts/TrueType-Reference-Manual/RM05/Chap5.html#DUP 2024-07-02 14:11:13 Stuff like DUP, SWAP, POP (drop) 2024-07-02 14:12:37 https://learn.microsoft.com/en-us/typography/opentype/spec/ttch01 2024-07-02 14:13:08 skvery: ^ 2024-07-02 14:49:04 i'm mulling a couple of words now to allow you to allocate and pivot to a new data stack 2024-07-02 14:50:33 For threads? 2024-07-02 14:50:45 surprisingly no 2024-07-02 14:52:27 What's the usecase? 2024-07-02 14:52:40 so that you can invoke callbacks in the middle of implementation code and the callback gets to see and manipulate the stack as the caller left it 2024-07-02 14:52:53 sorry on mobile and took me a while to type that 2024-07-02 14:53:06 Have you filled out your TPS Report yet? 2024-07-02 14:53:50 i don't do those 2024-07-02 14:54:08 i come in when i want and gut fish in the office 2024-07-02 14:55:13 Nice 2024-07-02 15:10:30 anyway, if there's a cleaner way to do this i would love to hear it. because trying to get the callee's working values out of the way before a callback is messy otherwise, except in the most trivial cases 2024-07-02 15:11:07 but i think that if i can figure out a nice way to do this, it paves the way for a neat, simple, more "functional" type of forth 2024-07-02 15:27:19 if the stack were a linked list this would be a lot simpler. it would just diverge here. 2024-07-02 16:23:40 interesting 2024-07-02 16:24:53 im thinking about a virtual machine for microcontrollers. I wonder if having several general purpose stacks could be useful. maybe specify which stack your callback can use 2024-07-02 16:28:44 that's the thing. it feels like a very heavyweight solution just for callbacks, and i'm worried that it's going to be unwieldy when i move to smaller targets. i wish i could think of a lighter way to do this. 2024-07-02 16:29:36 if you want a vm type of thing, you would want independent return stacks and instruction pointers, too 2024-07-02 16:32:01 i was also thinking of just a "save the stack pointer, leap ahead 8 or so cells, use this as my local stack, and then swap back to the original stack pointer for the callback" type of thing. at the moment that's probably where i'm headed, but i don't really like it either. 2024-07-02 16:33:08 maybe i should just abandon the notion that callbacks should get direct access to the top caller's stack view 2024-07-02 16:33:56 that seemed like a neat idea, just not sure it's worth it. 2024-07-02 16:46:19 Literally the problem you're solving here sounds like threads 2024-07-02 16:46:38 A thread is just a callback with a saved/working seperate stack 2024-07-02 16:47:02 If it's called by software only in certain times then it's a cooperative thread 2024-07-02 16:47:16 yeah 2024-07-02 16:47:45 Also the idea you had to pad 8 cells is literally how interrupt threads work 2024-07-02 16:48:34 well, "yeah" as in i understand that the solution that i'm describing sounds like threads. the problem doesn't mandate threads, though, and that's my struggle: i'm looking for a way to solve this without implementing threads. 2024-07-02 16:49:46 What I'm trying to say is I think your problem is equivalent to implementing software cooperative threads 2024-07-02 16:50:35 definitely not. the /solution/ i'm talking about atm may be, but not the problem statement. 2024-07-02 16:50:48 Okay, I agree with that 2024-07-02 16:51:11 Your suggested solution is equivalent to software cooperative threads 2024-07-02 16:51:42 and then only sort of. i'm only talking about parameter stack shenanigans, but they would still share a return stack. 2024-07-02 16:52:25 software coroutine then 2024-07-02 16:56:59 Waiting for someone to say 'this is just a closure' 2024-07-02 16:58:39 idk what you were talking about, but a closure is just a function with lexical scope and has attached some data by its enclosing scope 2024-07-02 16:59:19 yeah i've always wished for some clever cheap closure trick in forth :( 2024-07-02 17:00:10 i did some weird stuff to provide counters that are closures 2024-07-02 17:00:49 one of them was to attach to them a hash table where it's values are stored and perform the binding when executed 2024-07-02 17:01:25 a simple list attached to them would also do 2024-07-02 17:02:56 not a real closure maybe 2024-07-02 17:03:39 the state variables in C provide the same functionality a closure would provide 2024-07-02 17:04:55 i'm trying to stay very close to metal, so hash tables and runtime lookups are a bridge too far for me in this case. like i said: i'll probably just play with the stack pointer like i described. might end up adopting the closure vernacular for it, i'm not sure yet. 2024-07-02 17:05:10 a list is easier for forth 2024-07-02 17:05:37 but the way to provide a real closure should be to implement lexical scope properly 2024-07-02 17:05:46 since they are just a side effect of this 2024-07-02 17:06:06 yet you can provide the functionality you want from a closure in other ways, mainly attaching data to a word 2024-07-02 17:08:22 you're talking about this in terms of something like lisp or a prolog/c-type language. i understand these concepts in those contexts, but i think it's a mistake to think of them the same way in forth. 2024-07-02 17:11:22 a closure is a term from languages that use lexical scope and have first class order functions, which differs a lot from forth, but you might find a forthy way to implement them. Yet it depends if you want to provide lexical scope or not. In forth it seems to make no sense having lexical scope and a closure cannot be implemented without that. But y 2024-07-02 17:11:22 ou can always try different ways that are or behave similar and that align better with forth 2024-07-02 17:11:48 since i'm a forth noob, i cannot find a forthy way or even forth terms that align with it 2024-07-02 17:13:22 maybe just "scope" is the word i'm looking for 2024-07-02 17:13:41 but you are asking about a feature that comes from those languages and i can only define that term and give you ideas of what you would want from them or what you can use instead or what are they similar to, in order to help you find a proper way to implement them or have solidify your ideas 2024-07-02 17:14:14 i'm not asking about those features. i'm very familiar with threads and closures and first class functions. 2024-07-02 17:14:58 yeah, i'm not assuming your knowledge, just willing to help even if you might have even better knowledge about the subject than me 2024-07-02 17:15:51 anyway, if i describe what i'm thinking of simply as "scope" then i think the best analog to compare it to would be tcl's "uplevel" 2024-07-02 17:16:11 i think that's really what i'm describing: uplevel in forth 2024-07-02 17:16:16 i think the way should be using the return stack 2024-07-02 17:16:36 it's mainly how lexical scope is implemented in other languages 2024-07-02 17:16:48 DOES> stuff is pretty much a 'closure' or close as you'll get in Forth's classic glossary 2024-07-02 17:17:12 It's trite though 2024-07-02 17:18:24 but does not feel right to use the return stack for that 2024-07-02 17:18:28 does> as conventionally implemented or demonstrated is only a compile time template generator. Zarutian has described his system as having a runtime that's the only description of it i've ever seen approaching closures. 2024-07-02 17:24:43 It's not exactly a closure but it does solve the specific problem of associating function with longer-living state 2024-07-02 17:33:17 Whenever you take another language's concept and staple it onto Forth it's shit 2024-07-02 17:33:31 So usually I roll my eyes when the comparisons are made 2024-07-02 17:33:51 There's 3 kinds of languages, one of them is the 'Forth' kind, there's really nothing else like it 2024-07-02 17:48:15 yeah, that's why i was trying to avoid it :) 2024-07-02 17:48:47 particularly threads because i already intend to implement coroutines later down the road 2024-07-02 18:54:20 the important thing is that we all agree python sucks 2024-07-02 19:58:26 vms14: It took me forever to get my head around closures because the only way anyone would ever explain them was in computer science terms. When I finally "sort of got it" was when I could see it in terms of what was actually happening inside the machine / hardware. 2024-07-02 19:59:17 I don't know that I have it EXACTLY right still, and what I thought I got might just be a special case of it. But when I could imagine what went on inside the machine it was a lot easier for me to grok. 2024-07-02 20:01:09 if looking at hardware is what helped you understand closures, i suspect you didn't actually understand them. it's an abstract concept, not an implementation. 2024-07-02 20:04:34 there are many paths to understanding 2024-07-02 20:06:56 :-) 2024-07-02 20:07:34 i did not had any trouble understanding them when i saw them in a video of a mit class 2024-07-02 20:08:03 This guy contends there are seven "kinds" of languages. He calls them the seven Ur languages: 2024-07-02 20:08:04 https://madhadron.com/programming/seven_ur_languages.html 2024-07-02 20:08:05 i did have troubles with recursion because i did not understand where the values were going 2024-07-02 20:08:35 https://youtube.com/playlist?list=PLE18841CABEA24090 2024-07-02 20:08:39 yeah i work with these "understand one implementation types." they will usually talk like they understand it and the moment they encounter a characteristic that doesn't exactly match the implementation they have memorized, they think it is you who doesn't understand 2024-07-02 20:08:41 that's the course 2024-07-02 20:09:42 veltas: It would be interesting to know which ones of those you bunch into your three kinds. 2024-07-02 20:11:47 I think the reason I struggle with functional programming is related - when I think about programming I think about the "stuff I do" in my program as making changes to things. To RAM, or to peripherals, etc. etc. I.e., it's more or less all about the "side effects" in my mind. 2024-07-02 20:12:07 Consequently, the functional model almost strikes me as "not really doing anything." 2024-07-02 20:12:30 i always liked more fp than oop 2024-07-02 20:12:41 i was never a fan of oop actually 2024-07-02 20:13:11 I haven't ever used it much, but it was an easier model for me to grasp, because at least I could think of it as "doing something to the actual objects." 2024-07-02 20:13:21 i can understand their use and they can be handy, but i would prefer always the functional approach instead 2024-07-02 20:13:25 And then classes struck me as "instructions for how to do those things" to objects. 2024-07-02 20:14:44 I like the way modern Forths, like Mecrisp, brings you close into the chip where you can interact with on-chip modules without the tedious compile-download cycle. 2024-07-02 20:15:01 i always loved lisp's symbol property lists as some kind of cheap oop system 2024-07-02 20:15:28 functional, imperative, object oriented, aspect oriented, event driven, data driven... these things are all just tools in the toolbox. the problem is when people try to take any one of them to the extreme and claim "this tool can solve all problems!" 2024-07-02 20:15:30 in lisp every symbol has a property list where you can add whatever you want 2024-07-02 20:16:03 but you are better just using a hash table instead 2024-07-02 20:16:26 skvery: tethering? 2024-07-02 20:16:58 or on-device interpreter? 2024-07-02 20:17:14 yet in lisp you have one of the best object systems in the world, clos 2024-07-02 20:17:26 No, on chip with usb terminal. On device interpreter. 2024-07-02 20:17:26 never learned too much about it sadly 2024-07-02 20:54:01 I like being close to the hardware too. 2024-07-02 20:54:20 I see the value in tethered systems, but I usually think in terms of complete systems "on device." 2024-07-02 20:55:12 I was thinking over the weekend, though, about separating the compiler and the application into separate threads. Then I could possibly choose whether to run those on the same system or on different systems. Try for a design that lets me have either approach. 2024-07-02 20:55:18 Not sure yet - early thoughts. 2024-07-02 21:01:53 @+Kipingram Look at Mecrisp - it is exactly what you need. Get a chip that supports it - most of them are low cost, and try it. You will never look back. 2024-07-02 21:04:54 Yeah, I'm aware of Mecrisp. Big fan. I am dead set on writing something of my own, though. 2024-07-02 21:05:05 That's really the point - it's a hobby so to speak. 2024-07-02 21:05:23 I'm "also" interested in the things I do with it later, but I don't want to just use someone else's tool. 2024-07-02 21:05:44 I think Mecrisp Across in particular is just pretty brilliant.