2024-07-04 09:42:12 GeDaMo: I don't think it should be immediate 2024-07-04 09:42:15 , isn't immediate 2024-07-04 09:42:56 Yeah, s" would work to store strings in a compiled word 2024-07-04 09:49:58 Hmm S" S, 2024-07-04 09:52:25 s" parses, s, takes from the stack 2024-07-04 09:58:13 I mean you use both together as your 'immediate' ", 2024-07-04 09:58:30 I'm just talking aloud, don't know why :) 2024-07-04 09:59:02 Why would you need a reason? :P 2024-07-04 11:20:40 i think what makes ," weird for not being immediate is that it ends in a quotation mark 2024-07-04 11:36:49 Exactly 2024-07-04 11:37:27 But you can make up for that by putting quote in the name of any word that calls ," 2024-07-04 15:00:56 Yeah, I don't disagree with that from a usage perspective. 2024-07-04 15:01:38 But that " at the end of the name is intended to match with another one you type later, so if you compile ," into a new word you might want to consider ending it's name with a " 2024-07-04 15:01:47 Just to maintain that bit of visual goodness. 2024-07-04 15:03:11 So, more on this idea of splitting the interpreter/compiler and the "app" into separate threads. Somewhere out there there is a paper that talks about what they call a "three instruction Forth." It's intended to offer a way for fast bring-up of new hardware. 2024-07-04 15:03:36 Basically the three operations are peek, poke, and execute. So you get your new hardware able to do those three things, and then you can fully run it from a tethered host. 2024-07-04 15:03:50 That kind of interface could be how an interpreter/compiler thread runs an app thread. 2024-07-04 15:04:03 And then those threads could be on the same system or on different systems - it would work either way. 2024-07-04 15:04:31 I picture it as the app running under a simple "monitor" that implements those three ops or something equivalent to them. 2024-07-04 15:05:57 In the design I'm considering the code for any of those three ops will fit in a single cell, so my "interface" might be that the target receives a cell of code from the host and executes it. Over and over - that would really be all the monitor did. 2024-07-04 15:06:39 If the target produced console output, you'd also want to send that to the host. 2024-07-04 15:06:54 But I'm already planning that kind of I/O capability as a standard part of this system. 2024-07-04 15:07:05 Streams that I can re-direct to whereever. 2024-07-04 15:08:00 https://wiki.forth-ev.de/lib/exe/fetch.php/en:projects:a-start-with-forth:3_instruction_forth.pdf 2024-07-04 15:10:21 Anyway, I'm going to look at setting it up like that, even when I'm coding for a single platform system. Just to keep those doors all open. 2024-07-04 15:50:34 i had the dot word to print to the terminal or a file handle attached, so to redirect the output you just had to attach a filehandle and whatever dot printed would go there 2024-07-04 15:51:14 but from the user side, he had to provide code and the interpreter made that filehandle, attached it, executed the code and restore the file handle 2024-07-04 15:51:40 then it pushed a string on the stack, which would be a memory address in your cases 2024-07-04 16:48:00 I intend to have it at the system level - . and other output words will just output to the "standard output," and the system will know where to send that. 2024-07-04 16:48:21 No changes at all will be needed at the application level. 2024-07-04 16:49:07 I plan to emulate Linux in a lot of ways; each process will have the usual standard three, stdin, stdout, stderr, but more will be possible if the handles are created. 2024-07-04 16:49:48 In particular, a running interpreter won't know whether it's output is going to a local video display or to a serial port to be consumed by another computer - that will all just be transparent. 2024-07-04 17:40:34 what about this mechanism? an async word if executed leaves in the stack an integer id that is an id which will identify the result of its completion, then it creates a future that will be put in a map id->future, and when the current execution terminates, all queue futures are fired up, then when the user uses the word wait, it will pop from the stack an integer, will wait for that future to complete, and will put into the stack the result of that fu 2024-07-04 17:40:38 does it sound ok? 2024-07-04 18:14:11 what does "when current execution terminates" mean? 2024-07-04 18:15:44 that the current REPL read a line 2024-07-04 18:16:05 If you're aiming that at my discussion of I/O, then it seems a lot more involved than what I'm planning. 2024-07-04 18:16:15 Seems very fancy and computer sciencey. 2024-07-04 18:16:27 no well 2024-07-04 18:17:08 my basic problem is that i want to implement async i/o in my Forth, for instance, if i want to do `'www.microsoft.com' get-url wait` 2024-07-04 18:17:20 If an app wants to write to a specific file that it knows about, it'll have to open it and so on. But as far as standard output goes, I just want apps to "output," just like normal Forth. 2024-07-04 18:17:27 the get-url word pops a string from the stack and does async I/O do download the website 2024-07-04 18:17:28 What happens to it after that will be out of the app's sight. 2024-07-04 18:17:53 so it pushes a pid integer into the stack, then the 'wait' word will wait to that pid integer the result which is a string contaning the website 2024-07-04 18:18:00 get-url leaves something on the stack so wait knows what to wait for? 2024-07-04 18:18:08 Ok, yes. 2024-07-04 18:18:14 yes, it leaves an integer 2024-07-04 18:18:31 That seems fine; seems like it ought to work. 2024-07-04 18:18:48 there are better design for implementing I/O? 2024-07-04 18:18:55 i mean, async I/O 2024-07-04 18:19:00 You might also have it leave an xt, and wait would execute it periodically until it returned true or something like that. 2024-07-04 18:19:39 what is an xt? 2024-07-04 18:19:51 does the function running asynchronously have a separate stack for its use? 2024-07-04 18:19:54 Something you can EXECUTE. 2024-07-04 18:20:06 crc, no, why? 2024-07-04 18:21:14 if it's using the stack in the background, and you have something else running how do you keep track of the stack state? 2024-07-04 18:22:06 crc, oh, but the async function will be a builtin function that saves the computation in an hash table which maps pid->result 2024-07-04 18:22:12 You CAN use a caller's stack, but only if it's waiting until you're done and you guarantee you don't leave the stack in a different state from how you found it. 2024-07-04 18:22:37 so in a way, yes, they use a "different" stack, or btw, it doesn't write to the main stack 2024-07-04 18:27:13 ok, if not writing to the main stack that makes sense 2024-07-04 18:27:31 ACTION always finds actual asynchronous stuff confusing 2024-07-04 18:28:55 this is cool: https://archive.org/details/CAT240SC 2024-07-04 18:33:54 I think a hardware background (digital) helps with async. Same kind of situation where multiple things are going on at once, all with their own timings. 2024-07-04 18:34:12 for the few times I've played with concurrency, I've mostly used a modified version of my vm with multiple cores and just run the background bits on separate cores. Each has its own registers, data & address stack, but share access to the system memory 2024-07-04 18:34:19 And you have to plug them together in a way that will "work" regardless of random timing happenstance. 2024-07-04 18:35:43 that makes sense; it's one of the parts of hardware that I've had difficulty with as well 2024-07-04 18:48:41 joe9: thanks for sharing (Canon Cat source code); it's always interesting to look at old Forth code 2024-07-04 18:55:31 KipIngram, yes i agree 2024-07-04 19:09:44 joe9: http://www.canoncat.net/cat/Cat%20tForth%20Documentation.pdf (~38mb pdf) is documentation on the tForth system the Cat implements, which may be useful if trying to follow the source 2024-07-04 19:40:36 yes, that is an interesting document too. tForth seems to stick to the principles of Starting Forth closely.