2024-08-11 00:41:08 xentrac: if you're interested, I did a quick port of your wander.fs to my retroforth system (not an ANS/Forth20xx compatible system); see http://arland.xyz:9120/YD9 2024-08-11 04:28:07 crc: cool! 2024-08-11 04:30:39 the quotation syntax you use for, among other things, case, reminds me of the conditional syntax I used in StoneKnifeForth 2024-08-11 04:31:22 crc: the most important question: is it fun to play your version? 2024-08-11 04:33:42 unjust: I think if you can think through your problem well enough without using a computer, often a lot of small definitions isn't the best solution. Sometimes small definitions are useful because they're highly composable, so you progress towards the expressive power your application needs more rapidly 2024-08-11 04:34:17 but more often they aren't, and making them small is only useful because it facilitates interactivity and testability 2024-08-11 04:36:17 yes. I'll probably expand it a bit into something larger, but it's been enjoyable once I adjusted the key layout (I use Dvorak so changed my copy to use dhtn instead of hjkl) 2024-08-11 04:38:23 :) 2024-08-11 04:38:41 although Forth reduces the penalty for factoring to a minimum, which is one of the main reasons my C translation of the Forth is made of fewer, larger subroutines 2024-08-11 04:41:56 I think there's a very important sense in which it's harder to understand code in a larger number of smaller subroutines. in the Forth, for example, when you're reading : erase-dude bl set-dude ; (or RetroForth's :erase-dude #32 set-dude ;) you don't know under what circumstances it's being invoked 2024-08-11 04:42:27 later on as you're reading the code you can see that erase-dude is only ever called in one place, inside try-move 2024-08-11 04:43:06 in the C version I wrote `board[dude_y][dude_x] = ' ';` inside of try_move 2024-08-11 04:44:39 so while you're reading it, you know what preconditions have to have been met for that code to be running, and maybe you have a clearer view of the motivations for doing it, and — probably most importantly in this case — you can see that, three lines below, it says `board[y][x] = '@';` 2024-08-11 04:44:44 with no control flow in between 2024-08-11 04:45:34 so you know that the dude is never erased without being redrawn immediately afterwards in a new position, which is an important thing to know for understanding the code. it's something that the C style is more explicit about 2024-08-11 04:47:04 http://canonical.org/~kragen/sw/dev3/wander.fs is this the full program xentrac ? 2024-08-11 04:47:07 yes 2024-08-11 04:47:25 wild 2024-08-11 04:47:57 on the other hand, what I understand to be the Forth way there gives you more flexibility; you can invoke `erase-dude .board` interactively if you want. you can more easily change the fact that the dude is never erased without being redrawn immediately afterwards 2024-08-11 04:48:46 just quickly looking at the code I cant see the random generation part 2024-08-11 04:49:31 sorry, maybe I should un-abbreviate "random number generator" in the comment 2024-08-11 04:51:16 okay, fixed 2024-08-11 05:03:48 lf94: it's barely a game, it's *very* minimal 2024-08-11 05:07:28 another thing that I seem to have changed since I wrote http://canonical.org/~kragen/sw/dev3/midpoint.fs in 02016 and today is that I tend to use `value` more and `variable` less 2024-08-11 05:12:40 because y ← f(x) is `x f to y` with `value` and `x @ f y !` with `variable`, which seems worse to me because usually when I have a variable it's because my dataflow is branching *out*: I compute something in one place and use it in two or more places. so it seems more important to free variable reads from extra syntactic taxation (and opportunities for bugs, as the square-root asciicast I linked above 2024-08-11 05:12:46 embarrassingly demonstrated) 2024-08-11 05:15:02 crc: what does RetroForth do if you say `dude-x`? I see you have `!dude-x` and `@dude-x` but I never see the token without a leading sigil 2024-08-11 05:16:39 the downside of `value` is that it's maybe less flexible because if you decide that `y` should be something more than a simple variable, such as the y-coordinate of the current circle, you can't simply redefine `y` to compute the address in some way that depends on the current environment; you have to define a `y!` too, and change everything to use it 2024-08-11 05:27:50 xentrac: i think that small vs. large definitions for me usually comes down to what are my optimization & style preferences for that project/situation/environment 2024-08-11 05:29:48 unjust: that sounds interesting 2024-08-11 05:29:51 of course smaller definitions by their nature are likely to incur a lot more overhead with the branching and stack framing, but having source that's clearer to read is often worth a lose of potential perfomance if it's easier to understand at a glance 2024-08-11 05:31:37 s/lose/loss/ 2024-08-11 05:32:53 interestingly, I was thinking that smaller definitions are less clear to read 2024-08-11 05:34:03 I don't generally find them to be a performance problem. C and C++ compilers and LuaJIT are good at inlining, interpreters like CPython are so slow at everything else that subroutine calls aren't a major consideration, and Forth subroutine calls are extremely fast 2024-08-11 05:44:50 i guess what i'm really trying to say is that, often i aim for optimization for clarity at the expense of speed and/or size. i'm a fan of the concept of making functions/subroutines/procedures/words do one thing only. but there's a level of taste in terms of how small do you want to get with that granularity 2024-08-11 05:48:24 yeah, I like that concept too 2024-08-11 05:50:21 I think that in general it's better to optimize for clarity (not that wander.fs is any exemplar of what!) 2024-08-11 05:50:21 rather than for optimization ;) 2024-08-11 05:52:18 though there are certainly exceptions 2024-08-11 05:57:18 it's also interesting how language choice can influence those decisions 2024-08-11 05:57:59 yeah 2024-08-11 05:58:30 there isn't anything built into Gforth for this kind of thing, is there? 2024-08-11 05:58:32 : time utime 2>r execute utime 2r> d- drop ; \ measure μs of execution time 2024-08-11 05:59:17 the idea is that you use it as something like `' foo time .` 2024-08-11 06:00:47 time&date unfortunately does not have a useful amount of precision for this 2024-08-11 06:04:25 cputime is probably the best you're going to get: https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Keeping-track-of-Time.html 2024-08-11 06:05:15 there's somewhat of an example you can look at in ${PREFIX}/share/${GFORTH_VERSION}/onebench.fs 2024-08-11 06:08:30 hmm, that's probably more useful than utime for most programs, especially in the post-spinning-rust SSD age 2024-08-11 06:09:07 the (C) implementation of cputime is in the prim file in the same directory 2024-08-11 06:09:28 seems to rely on getrusage(2) 2024-08-11 06:09:45 since the chances that your program is running slowly without using much CPU time because it's waiting a lot on the disk are much lower than they used to be, and the chances that it's running slowly because your system is overloaded have not gone down as much 2024-08-11 06:12:25 crc: I like fetch-next 2024-08-11 06:48:29 xentrac: it's clear now. i thought maybe there was some intelligent design going on here :) 2024-08-11 06:48:41 for example, i thought it'd be impossible to have a spot where you cant go 2024-08-11 06:48:49 but no, it is possible there are many spots the player cant go 2024-08-11 14:11:40 Has anyone taken a different approach to loops than the usual DO..LOOP, BEGIN..DO..WHILE, etc? 2024-08-11 14:26:06 I've found this (1) https://blog.information-superhighway.net/a-forth-vocabulary-for-iteration and (2) https://lists.sr.ht/~vdupras/duskos-discuss/%3Cc186698e-6e30-4f54-8f10-c2db13c15381@app.fastmail.com%3E 2024-08-11 15:41:40 lf94: haha, yes, it is. it's even possible for the player to initially be walled in and unable to go anywhere! 2024-08-11 15:44:37 user51: interesting ideas! I think constructs for iteration are fertile grounds for experimentation 2024-08-11 15:45:22 e.g., Virgil's port of Python generators that you link 2024-08-11 15:49:31 the other interesting concept in the space is Alexandrescu's "ranges", which have been in the D standard library for a long time and have just been added to the C++ standard after many years languishing in Boost 2024-08-11 15:52:00 they're more flexible than the idea in the superhighway post because they are first-class; you can pass a partly consumed range to a subroutine, return it from one, or store it in a variable 2024-08-11 16:49:15 user51: the hip thing to do these days is to use quotation iterators 2024-08-11 16:49:35 or combinators or whatever tf they're called 2024-08-11 17:16:43 xentrac: you've given me an idea to further this "game". plop some cellular automata into the map. make them recognize the walls. try to escape! 2024-08-11 18:40:16 zelgomer: yeah but that requires quotations 2024-08-11 18:42:58 lf94: yeah, it wouldn't take much code to improve the map significantly. also for gamefulness it might be desirable to have some kind of objective; the simplest thing to do for that might actually be to remove the restriction on moving through walls, because as it stands dude will erase them 2024-08-11 19:21:48 then people would have the implicit objective of erasing all the walls. that would probably be more fun with less of them 2024-08-11 22:39:59 this is not a very clear implementation of union-find, is it? 2024-08-11 22:40:08 create dads size cells allot : dad cells dads + ; \ union-find structure 2024-08-11 22:40:08 : family dup dup dad @ <> if dup dad @ recurse tuck swap dad ! then ; 2024-08-11 22:59:09 hmm, unpleasant surprise: gforth's implementation of `dump` sets `base` to 16 2024-08-11 23:00:20 : dump base @ >r dump r> base ! ; 2024-08-11 23:00:57 but yeah, it would have been nice if dump restored it 2024-08-11 23:02:08 sure! 2024-08-11 23:02:18 one of those things that can cause some debugging headaches 2024-08-11 23:07:07 current PFE does support #80 and $A0 to disambiguate decimal vs. hex, but I don't think that was in ANS Forth in 01994 2024-08-11 23:07:24 PFE still doesn't support writing 65 as 'A' 2024-08-11 23:07:35 although the Forth 2012 standard requires that 2024-08-11 23:15:25 That doesn't seem appropriate for a language standard to me. 2024-08-11 23:15:35 But maybe I just look at it wrong. 2024-08-11 23:15:49 It means that you can't have a standard Forth on a system that doesn't use ASCII. 2024-08-11 23:16:19 Which is pretty ironic, given that Chuck regularly uses his own custom character encodings. 2024-08-11 23:26:19 yeah, the Forth 2012 standard requires ASCII 2024-08-11 23:26:52 but Chuck diverged from the standarization of Forth something like 35 years ago 2024-08-11 23:43:52 he sort of diverged from standardization of computing something like 50 years ago