2024-04-10 02:48:52 'sup! So after steping away from my project to create a colorforth-inspired computing ecosystem, a few days ago I started to feel an appeal to come back to it. Thing is, coming back at it, I see it with fresh eyes and half of it is not bad, the other half need rework. Basically so far I have a VM that is some sort of mix between UXN and also Chuck's F18a chip. I am at the point where I need to start making a forth on top of my vm and I 2024-04-10 02:48:52 am not sure how and where to start.. So I was just thinking of chatting a bit to see if it sparks some inspiration. :) 2024-04-10 02:51:56 For instance, I found out about this Able forth, apparently they initially explored the "words as token" concept from colorforth and retro to focus on only having parsing words. What do you think about that? What are the implication of a forth that put emphasis on defining parsing words? What could it look like? 2024-04-10 04:45:04 Sounds like you and I are thinking at least some of the same things - I'm also basing my next system heavily on the F18A. I'm not really looking at uxn per se - but I may have stumbled into some of the same areas by accident. 2024-04-10 04:47:16 I'm planning a virtual machine layer based on the F18A, but with some extensions I cooked up on my own, to contribute to very compact code. Then I'm going to implement the Forth itself as a code-threaded system written using that vm instruction set. So, only the vm emulator itself should require porting to new platforms - the rest should be a binary compatible "blob" that will move riht over to the new 2024-04-10 04:47:17 platform and just run. 2024-04-10 04:48:00 Hey KipIngram I remembler exchanging with you a year ago as well! Good to see you 2024-04-10 04:48:27 by code-threaded you mean STC? 2024-04-10 04:48:27 You too - welcome back. 2024-04-10 04:48:34 Yes, exactly. 2024-04-10 04:48:37 Thanks 2024-04-10 04:48:46 It'll be the first STC Forth I've ever written. 2024-04-10 04:48:58 I've done both direct and indirect threaded, but never this style. 2024-04-10 04:49:29 So that VM will operate something like a token-threaded system, and I'd always thought token-threaded == slow. 2024-04-10 04:49:57 But as I thought more about this I started to think it could potentially be as fast as or faster than any other system I've ever done. 2024-04-10 04:50:25 And yeah, you and I think alike! My goal is also a simple vm that can be easily ported and the forth system should be a binary image of the bytecode of that machine 2024-04-10 04:50:31 There actually IS a good "inner interpreter" for that sort of system. 2024-04-10 04:50:45 Yep - exactly. 2024-04-10 04:51:06 I've got some other ideas I want to roll in, so we likely diverge at some point. But it sounds like there is some commonality. 2024-04-10 04:51:15 The F18A is a really NEAT little architecture. 2024-04-10 04:51:59 It totally is, and I really am curious how it holds when implementing a forth on top of that 2024-04-10 04:52:20 I already deviated a little from the F18a tho 2024-04-10 04:52:21 My guess is "pretty well." 2024-04-10 04:52:30 Well, me too a bit. 2024-04-10 04:52:41 In certain ways, while keeping other aspects pretty intact. 2024-04-10 04:52:55 I've mostly just "thought about it" and written down notes so far. 2024-04-10 04:54:05 I expanded the instruction set to 64 so a "slot" is 6 bits 2024-04-10 04:54:41 I have a working implementation already, although it's far from the final state, do you want to check it out? 2024-04-10 04:54:50 I did too, but I will probably expand it a bit more (to 7 or maybe even 8 bits), because I want a "family" of "call opcodes" that call fixed distances back, with relative addressing. 2024-04-10 04:55:11 So that I can call "locally defined Forth words" using packed OPCODES instead of needing to embed an address for every call. 2024-04-10 04:55:42 So there might be 32 of these, so that I could call back to any of the last 32 cells. 2024-04-10 04:56:25 so like a "relative" call? 2024-04-10 04:56:33 That would mean, though, that when returning from a called word I'd need to be able to return to the next SLOT, not the next CELL. 2024-04-10 04:56:36 Yes, a relative call. 2024-04-10 04:56:51 The way I code Forth results in a lot of nearby "factored words." 2024-04-10 04:56:58 i'd like to be able to call them very compactly. 2024-04-10 04:57:10 why not a single opcode for "rcall" then? 2024-04-10 04:57:25 Well, it would need an operand. 2024-04-10 04:57:41 I will probably have that too - or at least something like the F 18A's existing call instruction. 2024-04-10 04:57:52 the next slot contains the signed value 2024-04-10 04:58:21 Yes, I know, but I want to be able to avoid that. Because then a string of calls would take a whole lot of cells. 2024-04-10 04:58:33 I'd like for it to use a string of SLOTS instead of a string of CELLS. 2024-04-10 04:58:50 I think it would make the code order of 4x more compact. 2024-04-10 04:59:06 I mean a rcall uses 2 slots instead of a whole cell, not too bad imo 2024-04-10 04:59:44 Yeah, I do see what you're saying. So you are NOT talking about the pure F18A call, which uses the entire remainder of the cell for the offset regardless of how much is needed. 2024-04-10 05:00:02 You're talking about, for example, a six-bit instruction followed by a six-bit cell offset. 2024-04-10 05:00:08 That's a reasonable approach too. 2024-04-10 05:00:10 exactly 2024-04-10 05:00:31 you can still keep the "normal" call too 2024-04-10 05:00:36 Yes. 2024-04-10 05:00:49 And I would, because sometimes I'd need to be able to call very far away t hings. 2024-04-10 05:00:51 but that just add a single new opcode instead of 32 :D 2024-04-10 05:00:58 Yes, but think about this. 2024-04-10 05:01:03 Say you have 6-bit opcodes. 2024-04-10 05:01:11 You can get five of them in there, with 2 bits leftover. 2024-04-10 05:01:21 exactly 2024-04-10 05:01:21 Now and then you might be able to use those two bits. 2024-04-10 05:01:25 that's what I do 2024-04-10 05:01:26 But not often, mots likely. 2024-04-10 05:01:32 Now say you use 7-bit opcodes. 2024-04-10 05:01:44 You get four opcodes but now you have FOUR bits leftover. 2024-04-10 05:01:55 That will lead to that spare slot being usable considerably more often. 2024-04-10 05:02:07 So you will often get five instructions per cell either way. 2024-04-10 05:02:38 Honestly, I think it's hard to know which of these would be best without trying them and comparing the results. 2024-04-10 05:03:16 I can too, and sometimes 6 with 6 bits opcode, my 3 "special" opcode are the most common: 'ret', 'unext' and 'noop' 2024-04-10 05:03:22 Have you given much thought to which instructions you'd make "qualifiy" for the 2-bit slot? 2024-04-10 05:03:33 yes 2024-04-10 05:03:37 I figured ret would probably be one of them. 2024-04-10 05:03:43 unext is a must for instance 2024-04-10 05:03:51 Right right - and unext. 2024-04-10 05:03:54 Me too. 2024-04-10 05:04:00 I was having trouble remembering unext. 2024-04-10 05:04:03 that way you get a very cheap 5 slot loop 2024-04-10 05:04:13 But, clearly - you want to be able to do 5-instruction uloops. 2024-04-10 05:04:57 and noop for the last, so I can pad when it's not ret or unext 2024-04-10 05:05:04 There is a penalty for avoiding having calls consume the whole rest of a cell - you have to support returning to within the middle of a slot. 2024-04-10 05:05:15 That means having a return address ANd an instruction word in your return stack frame. 2024-04-10 05:06:07 But, pushing two items to the return stack is likely almost as fast as pushing one, because pushing one gets that cache line into your cache. 2024-04-10 05:06:08 yeah I just don't do that 2024-04-10 05:06:12 So the second push will be very fast. 2024-04-10 05:06:24 And likewise the second pop on return. 2024-04-10 05:06:35 I think the speed difference would be hard to even measure. 2024-04-10 05:06:50 new definition would always start on a new cell 2024-04-10 05:07:00 Yes, new definitions definitely will. 2024-04-10 05:07:07 CALLS will be to cells, not slots. 2024-04-10 05:07:13 and jump can only jump to a cell too 2024-04-10 05:07:20 Yes. 2024-04-10 05:07:37 you want to see my current implementation? 2024-04-10 05:07:41 At any rate, we should stay in touch - we're working in neighboring areas, so we should hsare ideas. 2024-04-10 05:07:42 https://git.blazebone.com/pochi/tree/pochi.c 2024-04-10 05:07:52 for sure!! 2024-04-10 05:07:56 Oh, sure. I don't really have anything to share back yet. 2024-04-10 05:08:13 I've been off distracted by other things just like you have been - maybe this will help incentify me to get back into this. 2024-04-10 05:08:33 ofc, maybe we could even come up with a common more generic vm instruction set!?? 2024-04-10 05:09:48 Sure possibly. I have some kind of strange ideas on that front though. I won't get into them tongiht; it's been a long evening. Next time maybe. Last year I bought about a half-dozen little microcontroller boards. Arm processor with a slew of integrated peripherals. My notion is that I want to get this system onto that guy and use it as the "starting point" for all my future hardware projects. 2024-04-10 05:10:07 This one: 2024-04-10 05:10:09 https://www.analog.com/media/en/technical-documentation/data-sheets/MAX32655FTHR.pdf 2024-04-10 05:10:40 It's got all the goodies. Bluetooth, digital I/O, serial, timers, etc. etc. etc. 2024-04-10 05:10:40 since or goal is to create a vm based on the F18a and build a forth on top, maybe the fact that we'll build build different forth could make the IS more robust! 2024-04-10 05:10:55 Yes. 2024-04-10 05:11:31 oooh nice, let's think about this, I wanted to rework the device access as well 2024-04-10 05:11:56 Yeah, I picture this as an "OS" for that little board, among other possibilities. 2024-04-10 05:12:20 My "dream" is to use the board's bluetooth to make it possible to open a console to it wirelessly. 2024-04-10 05:12:33 Pretty tall order, since I don't really know anything about Bluetooth yet. 2024-04-10 05:13:14 we should definitely keep in touch then, my "pochi" vm is supposed to have a port in which you can stream cells of instructions 2024-04-10 05:14:07 I want that kind of thing too, because if I DO use this to run future hardware projects, I'm going to want to interact with those things from my computer, and IT should be running a compatible system, so that they can do exactly that. 2024-04-10 05:14:12 if you wrote a bluetooth device and add it as a new device, I could imagine it being able to have wireless console 2024-04-10 05:14:14 sort of a "distributed system." 2024-04-10 05:14:20 Notebook + gadget. 2024-04-10 05:14:35 exactely the idea 2024-04-10 05:15:05 you'll see my email on the about of the repo: https://git.blazebone.com/pochi/about/ 2024-04-10 05:15:29 https://merveilles.town/@neauoire/112244675323957151 I hope I'm not the only one who thinks that DIG/BURY are much better names for ROT/-ROT :D 2024-04-10 05:15:35 we should definitely try to think more about this together 2024-04-10 05:16:29 I constantly find myself needing to look for the stack effect of ROT to remember how it works to a point it's almost embarrassing 2024-04-10 05:16:42 coyote: wow, I agree with that 2024-04-10 05:17:05 exhume instead of dig 2024-04-10 05:17:36 exhume/inhume 2024-04-10 05:18:04 Hehe 2024-04-10 05:18:06 I'm punching out for the night now, nature - I'll ping you soon. Take care. 2024-04-10 05:18:13 so now you have to look at an english dictionary for the stack effect :D 2024-04-10 05:18:13 i also think tuck should have been called under 2024-04-10 05:18:23 KipIngram: please do! take care! 2024-04-10 05:18:24 over/under 2024-04-10 05:18:37 ^ That makes pretty good sense. 2024-04-10 05:18:42 ACTION nods 2024-04-10 08:26:35 KipIngram I would use Mecrisp Forth. https://mecrisp-stellaris-folkdoc.sourceforge.io/ 2024-04-10 12:06:26 skvery: You mean for controlling hardware projects? I do like mecrisp quite alot - part of the fun of this for me, though, is building it myself. 2024-04-10 12:08:52 Yes, and it also exposes the basic Forth as GAS code. Handy to optimise sections of code as required. 2024-04-10 12:08:57 I'd also like to try to do it without using any "dev" tools at all - you can program the MAX32655 by just dropping a firmware image file on the "storage device" it presents when you connect it to your computer; I'd like to write a C or Python program that produces that image file (and will actually emulate the vm so I can use that tool to develop the Forth code, too). 2024-04-10 12:10:20 The handy thing with MForth is that you are close to the hardware without the continious compile-link-download cycle. 2024-04-10 12:10:55 You can get to the modules via the bare bones. 2024-04-10 12:11:04 Yes, the very first time I read about mecrisp I was impressed with it. It looked practically ideal for developing code for devices that can't host an entire Forth themselves. 2024-04-10 12:11:55 Just getting the gadget to run isn't my only goal, though - creating these Forth systems from scratch is kind of a "hobby." 2024-04-10 12:12:24 Try Mecrisp - download it and use it interactively - The main mecrisp thread. 2024-04-10 12:13:14 * download it to the MAX32655 and use it interactively to talk to the modules. 2024-04-10 12:21:01 I probably won't - that's just not how I want to approach the work. I want to do something entirely on my own. I'm not claiming it's the most "get it done" effective approach; there's an entertainment factor here for me as well. 2024-04-10 12:21:01 One will have to move the C library to AS and the create the on chip Forth Command interface to run BLE. I started a project like this some time ago for the Microbit but ran out of spare time to proceed. 2024-04-10 12:21:35 Yes, spare time is always an issue. Plus it's not the only thing I want to put some spare time into. :-) 2024-04-10 12:21:50 https://makeprojects.com/project/get-the-bbc-microbit-to-speak-mecrisp-forth-over-bluetooth 2024-04-10 12:23:40 With Mecrisp the full Forth intrpreter is available on chip. It is very fast as well. To rebuild that will be a lot of work. 2024-04-10 12:26:08 Is that MAX board supported by mecrisp? Peripherals are completely different on different chips so it won't run without some customization 2024-04-10 12:27:29 Also, you're probably not going to be optimizing any mecrisp source yourself. It has primitives and produces optimized machine code which is uncommon 2024-04-10 12:30:21 The AS code is available - so customisation to any board layout or any specific perferal, like BLE is possible. 2024-04-10 12:30:58 Jus a little assembler coding - good for the soul. 2024-04-10 12:31:04 *Just 2024-04-10 12:33:09 $33 is a fair price... 2024-04-10 12:51:20 > I started to feel an appeal to come back to it 2024-04-10 12:51:42 Story of everyone here, nobody here ever thought "I want to be into Forth" 2024-04-10 12:51:56 We keep leaving and coming back when we get headaches and the shakes 2024-04-10 12:54:10 Forth is very powerful to discover and low-level debug on-chip perpherals. 2024-04-10 13:00:18 ACTION has stuck with using forth contitually since discovering it in 1998 2024-04-10 13:05:20 I am joking a little bit 2024-04-10 13:05:41 crc: It definitely shows, in your code! 2024-04-10 13:05:55 crc is on the wizard end of the spectrum 2024-04-10 13:10:26 I'll say even though I don't write retro, crc's articles and what he's shared has been quite influential on my Forth programming 2024-04-10 16:17:34 My forth shit is growing lol. 2024-04-10 16:17:56 https://gist.github.com/lf94/796d4a743c36ffbe04b6e1ea24c5441e 2024-04-10 16:18:23 Mr Forth would not be happy with the amount of stack Im using 2024-04-10 16:18:47 It would be better to allocate dictionary space for these operations 2024-04-10 16:18:54 But that takes up space :) 2024-04-10 16:19:12 The main advantage here is it takes up less space 2024-04-10 16:20:04 But what I really care to show you guys 2024-04-10 16:20:09 is this assert=.. I created 2024-04-10 16:20:11 https://gist.github.com/lf94/796d4a743c36ffbe04b6e1ea24c5441e#file-sha256-f-L173 2024-04-10 16:20:28 So I'm starting to create my own "standard" of having test cases right after definitions 2024-04-10 16:21:15 I'll paste it inline here so you don't have to click through 2024-04-10 16:21:17 \ full rotation 2024-04-10 16:21:19 1 2 3 4 4 bytes 32rr 2024-04-10 16:21:21 1 2 3 4 4 assert=.. 2024-04-10 16:21:36 At the end of all the tests for a definition, I end it with 2024-04-10 16:21:40 depth 0 assert= 2024-04-10 16:21:51 to be sure the stack is clean 2024-04-10 16:22:13 The tests also pretty much provide extra documentation 2024-04-10 16:22:21 lf94: 32dup might just be 2over 2over 2024-04-10 16:22:37 Sure but I was thinking to expanding this to 64bits and maybe even 128bits 2024-04-10 16:23:04 I was going to create a more generic function 2024-04-10 16:23:15 dupb or something 2024-04-10 16:23:29 I should probably not though 2024-04-10 16:23:42 I should really stop after this and get to graphics tuff 2024-04-10 16:23:45 Well, there's pick 2024-04-10 16:25:09 It might be better to have array operations and keep the values in memory 2024-04-10 16:25:28 Is that not what I said earlier? 2024-04-10 16:25:38 (Just making sure I'm using terminology right) 2024-04-10 16:25:51 lf94: Sometimes the extra work to manipulate stack takes up dictionary in the end anyway 2024-04-10 16:25:53 Oh yeah, I missed you saying dictionary space :P 2024-04-10 16:25:54 Can't win 2024-04-10 16:26:08 veltas: aaaa! that's a really good point 2024-04-10 16:26:19 damn, I was silly to think I was saving space. that definitions were free... 2024-04-10 16:26:24 Exactly 2024-04-10 16:26:35 I might refactor this 2024-04-10 16:26:40 probably not 2024-04-10 16:26:43 Simple memory defs where you just need some dumb vars is better than extra stack work to keep dynamic 2024-04-10 16:26:48 But the stack stuff is reentrant 2024-04-10 16:26:50 seriously I *really* want to get into graphics and networking with forth 2024-04-10 16:27:00 But in Forth you shouldn't code for things you don't know if you need 2024-04-10 16:27:05 And reentrancy you probably don't need 2024-04-10 16:27:27 You can do graphics and networking in forth, absolutely 2024-04-10 16:27:31 I never understood what reentrancy meant 2024-04-10 16:27:42 I'm probably misusing but basically 'thread-safe' for this context 2024-04-10 16:27:51 That's not what it means really but essentially that's what I mean here 2024-04-10 16:27:59 am I doing that or something 2024-04-10 16:28:33 If you put everything on stack then it's more naturally reentrant, but using dumb vars often makes smaller dictionary overall 2024-04-10 16:28:42 There are many ways to skin a cat 2024-04-10 16:29:16 aaaa I get your mental model about this now 2024-04-10 16:29:26 You really have to just cut your teeth and try different ways of handling data 2024-04-10 16:29:29 because I did it this way, im naturally making reentrant functions 2024-04-10 16:29:32 Because they're all valid in different situations 2024-04-10 16:29:54 I find reentrant functions easier to reason about 2024-04-10 16:30:05 Easier from modern background 2024-04-10 16:30:09 true 2024-04-10 16:30:29 Old-school programming languages lended to non-reentrant code, and the reality is that's easier to write in older machine architectures 2024-04-10 16:30:33 Especially e.g. 6502 2024-04-10 16:31:01 All 8-bit arch's really 2024-04-10 16:31:31 how would you do an assert=.. ? two pointers to two [len, data] ? 2024-04-10 16:31:58 Not sure what you mean 2024-04-10 16:32:06 \ full rotation 2024-04-10 16:32:08 1 2 3 4 4 bytes 32rr 2024-04-10 16:32:10 1 2 3 4 4 assert=.. 2024-04-10 16:32:12 for context 2024-04-10 16:32:25 32rr returns 1 2 3 4 again 2024-04-10 16:32:28 I just wouldn't handle that on stack honestly 2024-04-10 16:32:44 yea yea. what im saying is, would you instead do like 2024-04-10 16:32:51 ptr1 ptr2 assert=.. ? 2024-04-10 16:33:05 I'm using .. as "list" 2024-04-10 16:33:15 or "many" 2024-04-10 16:33:24 Ive actually really been liking it 2024-04-10 16:33:29 instead of [] 2024-04-10 16:33:50 If it was contiguous I might do e.g. DATA CHECK with : CHECK CORRECT LEN COMPARE ABORT" mismatch" ; 2024-04-10 16:34:24 yea it's contiguous 2024-04-10 16:34:49 what is "correct" ? 2024-04-10 16:35:05 There's no correct way 2024-04-10 16:35:16 no I mean the 'CORRECT' word 2024-04-10 16:35:45 CORRECT would be e.g. CREATE CORRECT 1 C, 2 C, 3 C, 4 C, 4 C, 2024-04-10 16:35:50 LEN would be 5 2024-04-10 16:36:02 Or with , and 5 CELLS if they're not bytes 2024-04-10 16:36:15 So just have another array with the 'right' values 2024-04-10 16:36:19 but that data is hardcoded like that 2024-04-10 16:36:21 hm 2024-04-10 16:36:29 So don't change it ;( 2024-04-10 16:36:32 ;) * 2024-04-10 16:36:52 how does 'COMPARE' work? 2024-04-10 16:37:13 It's a standard word 2024-04-10 16:37:13 oh, is this a string function? 2024-04-10 16:37:33 Really I haven't balanced stack there, needs another length 2024-04-10 16:37:40 I think COMPARE takes two 'strings' yeah 2024-04-10 16:37:47 hm, cant find it in core 2024-04-10 16:37:53 https://forth-standard.org/standard/core 2024-04-10 16:37:56 So should be : CHECK LEN CORRECT LEN COMPARE ABORT" mismatch" ; 2024-04-10 16:38:04 IMO this should be in core 2024-04-10 16:38:05 It's in string words maybe 2024-04-10 16:38:30 How do I propose to move this into core lmao 2024-04-10 16:38:53 There's a procedure on their website 2024-04-10 16:38:57 https://forth-standard.org/standard/string/COMPARE yea 2024-04-10 16:39:34 I personally don't care about the new standard 2024-04-10 16:39:51 Not gonna lie, at least with core, it's been nice 2024-04-10 16:40:02 I realize I reinvent something, then see it's in core 2024-04-10 16:40:07 and im like damn, nice 2024-04-10 16:40:23 if other impls _just_ do core im super happy 2024-04-10 16:40:24 The core words are mostly words you'll see in some form on all forths 2024-04-10 16:40:36 that's why id like to see compare there 2024-04-10 16:40:38 Most people here only really even write for ANS Forth if they want portable code, and don't follow Forth 200x at all 2024-04-10 16:40:42 compare doesn't belong in core 2024-04-10 16:40:51 it a super common thing: compare two variable length things 2024-04-10 16:40:54 compare is like memcmp. it's a library function. 2024-04-10 16:41:06 yes, it's memcmp 2024-04-10 16:41:08 but why not 2024-04-10 16:41:09 yes but it's implemented in terms of core words 2024-04-10 16:41:15 hm 2024-04-10 16:41:17 gotchya 2024-04-10 16:41:21 core words are all assembly? 2024-04-10 16:41:24 from what I saw: no 2024-04-10 16:41:29 core should be the minimum primitives that may be used to implement all other words 2024-04-10 16:41:43 how they're implemented is, obviously, implementation defined 2024-04-10 16:42:05 "compare" under string though feels wrong 2024-04-10 16:42:19 sorry for your loss 2024-04-10 16:42:22 haha 2024-04-10 16:42:23 anyway i don't know why i'm speaking up. i don't care about the standard, either. it sucks. 2024-04-10 16:42:38 I would love to hear why you guys think it sucks 2024-04-10 16:42:42 It could really save me some time 2024-04-10 16:42:55 https://dl.forth.com:8443/sitedocs/dpans94.pdf 2024-04-10 16:43:16 because the spirit of forth is about writing the language you need to solve the problem at hand. it's not about unifying all forths under a single restrictive standard. 2024-04-10 16:43:21 Maybe I should write an article, I don't want to get cited though 2024-04-10 16:43:54 I think you should write an article, and if you care about that, post it as an anonymous user on reddit or something 2024-04-10 16:43:59 I'll spread it on your behalf :P 2024-04-10 16:44:06 Even if you think a 'standard' Forth is a good idea, which I don't think it's such a bad idea, they have made a lot of bad decisions 2024-04-10 16:44:15 And it feels very unforthy and inconsistent 2024-04-10 16:44:33 zelgomer: gotchya. 2024-04-10 16:44:49 zelgomer: don't you think though things like "dup" being a standard forth word is... nice? 2024-04-10 16:44:51 lf94: btw, memcmp comes from string.h 2024-04-10 16:45:02 lmao, ooof, ok. well you got me there 2024-04-10 16:45:13 For example since ANS they've had a word called ENVIRONMENT? which is a total mess, a core word, and just terribly designed 2024-04-10 16:45:29 It's the only core word I didn't implement for zenv and nobody's noticed or complained 2024-04-10 16:45:57 lf94: nice for who? who is harmed if i choose to call my dup "copy" instead? 2024-04-10 16:46:06 There's a million ways they could have better achieved the environment feature 2024-04-10 16:46:19 And the whole concept is still very unforthy anyway 2024-04-10 16:46:40 It's dynamic compatibility info, it's just not even useful in most programs, yet it's core 2024-04-10 16:46:46 zelgomer: well say i want to use your forth because it's the only one on a system, or its the best one on the system... 2024-04-10 16:47:03 veltas: wow, that *is* crappy 2024-04-10 16:47:11 if you're using something i wrote, you'd better read the documentation 2024-04-10 16:47:28 zelgomer: yeah. it just makes my day harder 2024-04-10 16:47:33 maybe it's a mindset thing 2024-04-10 16:47:41 maybe it's business programming rotting me 2024-04-10 16:47:43 documentation made your day harder?? 2024-04-10 16:47:47 no no 2024-04-10 16:47:55 having to read your documentation and rewrite parts of my code 2024-04-10 16:48:02 to use _your_ system 2024-04-10 16:48:05 it's selfish of me 2024-04-10 16:48:26 how would you have code for my system to rewrite before you've even seen my system? 2024-04-10 16:48:36 I believe the goal of any standard is to make it easier for humans to interact with each other 2024-04-10 16:48:44 Being able to write code that works on many forths is useful to some people, if you care about that then you can target a standard. But zelgomer doesn't care, and that's his prerogative. 2024-04-10 16:49:38 zelgomer: example, this sha256 impl. it's stack based. it should be pretty close to "already working" on zelgomer-forth, but i would have to read documentation still and rewrite some parts 2024-04-10 16:49:50 Non-standard forths often have attractive/clever designs. It's just not a good idea IMO to go non-standard if you're inexperienced, as you probably won't do better than the old-school forth design 2024-04-10 16:50:15 maybe the word "standard" is really bad 2024-04-10 16:50:25 instead it should be "bootstrap" 2024-04-10 16:50:30 lf94: but i don't need a sha256 for anything that i'm doing right now 2024-04-10 16:50:35 get you into the forth world, into the forth mindset 2024-04-10 16:50:57 this is the mindset that you're missing. i'm not trying to create a portable environment. i'm writing code to solve very specific problems in very specific environments. 2024-04-10 16:51:34 zelgomer: gotchya. so you create a new forth for each? 2024-04-10 16:51:56 that's the idea 2024-04-10 16:51:57 that's next level forth thinking 2024-04-10 16:52:07 I'd concur with veltas on . My systems were much more traditional in the past. 2024-04-10 16:52:13 no, it's actually consistent with original forth thinking as far as i can tell 2024-04-10 16:52:44 zelgomer: sorry, to a beginner, or someone new to the space, it appears "next level" 2024-04-10 16:52:54 A word like "dup" feels fundamental. 2024-04-10 16:52:58 It's probably one reason nobody really cared when e.g. fig agreed to stop releasing forths 2024-04-10 16:53:22 Everyone was maintaining their own by that point or willing to work with new incompatible designs on better systems 2024-04-10 16:54:04 makes me think we need better documentation systems 2024-04-10 16:54:07 at the end of the day 2024-04-10 16:54:13 lf94: which is why i've tried to encourage you to not make mistakes that i've made in the past by trying to write "one forth to rule them all" before you've actually spent time learning the language and the ideas behind it to understand why that's a bad idea 2024-04-10 16:54:51 well Ive been using standard-forth.org purely for core words as documentation to quickly know what most forths give me 2024-04-10 16:55:07 but other than that I try to avoid everything else purely to practice building up words 2024-04-10 16:55:12 Get a copy of https://dl.forth.com:8443/sitedocs/dpans94.pdf 2024-04-10 16:55:16 (as youve seen in my snippet link) 2024-04-10 16:55:21 veltas: roger 2024-04-10 16:55:25 i actually have no idea who run forth-standard.org or who is contributing to it. i don't recognize any of the names i've seen on that site. 2024-04-10 16:55:39 lf94: ANS Forth, smaller and older standard, more forths will support that set of words if you're concerned with compatibility 2024-04-10 16:55:59 And it's a good base to start on, learn with, etc 2024-04-10 16:56:05 I care just knowing the core set of forth to build a forth mindset 2024-04-10 16:56:13 I have to actually write forth programs to learn this 2024-04-10 16:56:18 cool :) 2024-04-10 16:56:22 zelgomer: It's the forth-200x group who are behind Forth 2012 etc 2024-04-10 16:56:36 Seems like there's gforth people involved and some people I've seen on stack overflow 2024-04-10 16:57:31 I feel gforth is only recommended because of the GNU name 2024-04-10 16:57:39 None of these websites are maintained that well, e.g. gforth's 2-3 websites which haven't seen a release for over a decade now 2024-04-10 16:57:53 Anyway more important topic: how do people normally wire up networking into their forth? and graphics? 2024-04-10 16:58:05 gforth is recommended because it's actually not bad, it uses GCC to generate optimised code, it's all open source. 2024-04-10 16:58:17 There's BigForth(?) which did OpenGL 2024-04-10 16:58:19 gforth's issue is just being bloated, it's not very forthy in that sense, but it's available everywhere 2024-04-10 16:58:28 And not doing a proper release in forever 2024-04-10 16:58:40 I feel rolling release really fits forth well 2024-04-10 16:58:49 All 'good forths' on desktops support C FFI 2024-04-10 16:58:55 https://github.com/forthy42/bigforth 2024-04-10 16:59:02 Should I pay for one of the commercial forths? 2024-04-10 16:59:05 So you can call C functions, e.g. the system interfaces, libraries etc 2024-04-10 16:59:06 Oh! Another thing: jobs. 2024-04-10 16:59:12 There's no jobs 2024-04-10 16:59:17 I figured not 2024-04-10 16:59:23 Don't pay for a commercial forth 2024-04-10 16:59:24 But internally are you using forth for anything 2024-04-10 16:59:39 Try swiftforth demo, it's not bad, but you obviously can't sell anything you make with that 2024-04-10 16:59:46 http://bernd-paysan.de/bigforth.html 2024-04-10 16:59:48 crc has used forth for contracting 2024-04-10 16:59:50 thanks GeDaMo 2024-04-10 17:00:06 crc can you share? 2024-04-10 17:00:15 that's some real interesting experience I'd love to hear 2024-04-10 17:00:17 I've used forth at work internally, I might use it more as my forth / packages get more developed 2024-04-10 17:00:52 I have written a number of programs in Forth, both for one off jobs and for my employer. 2024-04-10 17:00:52 And might use for my website to generate pages, have some ideas for that, right now my content generation is a makefile so not too complicated to replace 2024-04-10 17:00:54 I was telling myself: it seems forth could be really useful in the work place if I build up string words, then parser words, then json words, then networking words 2024-04-10 17:01:27 that settles like 99% of all web stuff 2024-04-10 17:01:29 JSON is not forthy though 2024-04-10 17:01:36 I know. But you gotta compromise for web stuff 2024-04-10 17:01:51 Forth allows writing DSL's easily, might consider trying to fit it to that model 2024-04-10 17:02:08 The syntax that's easy to work with in Forth isn't JSON or C-style 2024-04-10 17:02:19 I'm talking more about parsing json and outputting json 2024-04-10 17:02:23 Most of the one offs have been for data processing tasks. No fancy interfaces, just reading in raw data from CSV & TSV sources, doing lots of calculations, and creating reports based on the data. 2024-04-10 17:02:48 crc: nice. see, a collection of parser words would be perfect for that: creating a CSV parser. TSV parser. JSON parser. 2024-04-10 17:03:16 the stuff for my employer is mostly a web app that we use to track customer information, order data, some inventory stuff, and our delivery drivers. 2024-04-10 17:03:38 is it in retroforth? 2024-04-10 17:03:45 (iirc that's you right) 2024-04-10 17:03:47 I don't have a JSON parser. I use jq for that, under a unix pipe 2024-04-10 17:03:51 yes, in retroforth 2024-04-10 17:03:52 ah. 2024-04-10 17:04:06 what are you having your forth output 2024-04-10 17:04:13 your output must be fairly flat? 2024-04-10 17:04:17 er 2024-04-10 17:04:19 input 2024-04-10 17:04:22 It helps to fit the code to the task at hand, generic JSON code is probably a misstep in Forth or anywhere 2024-04-10 17:04:58 veltas: a json parser on the forth side could be useful. imagine you have a forth on a microcontroller that can parse json stored in a qr code 2024-04-10 17:05:02 (i know, stupid use of json.) 2024-04-10 17:05:12 Be specific though, what's it for 2024-04-10 17:05:30 Input data comes from various sources, it's normally easy to restructure into a consistent format for intake. 2024-04-10 17:05:38 ill use the pandemic example: medical notes 2024-04-10 17:05:47 The general solution requires e.g. generating a tree structure and putting it all in memory, or adding loads of callbacks and rules 2024-04-10 17:05:58 I have a lot of tooling around that, much of which is many years old now 2024-04-10 17:06:05 But specific solutions can skip that crap and just churn data line-by-line etc 2024-04-10 17:06:16 Don't need full JSON support, full tree traversal etc 2024-04-10 17:06:27 "full json support" is pretty trivial iirc 2024-04-10 17:06:29 maybe im wrong 2024-04-10 17:06:38 KISS 2024-04-10 17:06:44