2026-06-16 16:37:29 <bjorkintosh > so forth-wrights. what's new in the forth world? any new books?
2026-06-16 17:05:46 <veltas      > Hi bjorkintosh, nothing I've heard about
2026-06-16 17:06:55 <bjorkintosh > same old, still new?
2026-06-16 17:08:41 <veltas      > Still new?
2026-06-16 17:09:53 <bjorkintosh > yes veltas. the same old material is still viable.
2026-06-16 17:09:58 <bjorkintosh > perennial.
2026-06-16 17:10:04 <bjorkintosh > evergreen.
2026-06-16 17:10:17 <xentrac     > crc's Ilo/Konilo is cool: http://ilo.retroforth.org/latest/ilo.c
2026-06-16 17:10:44 <iv4nshm4k0v > JFTR, there's the news:comp.lang.forth newsgroup where new Forth-related stuff is posted from time to time.
2026-06-16 17:11:28 <xentrac     > vdupras wrote a new Forth tutorial which I haven't read: https://tumbleforth.hardcoded.net/
2026-06-16 17:12:16 <bjorkintosh > the usual suspects.
2026-06-16 17:12:18 <xentrac     > but it seems promising to have a Forth tutorial (a) directed at a 21st-century audience using 21st-century platforms and (b) written by someone who isn't a total Forth beginner
2026-06-16 17:13:43 <bjorkintosh > thank you iv4nshm4k0v
2026-06-16 17:16:30 <xentrac     > Mecrisp has apparently been ported to RISC-V: https://github.com/hansfbaier/mecrisp-quintus/blob/main/mecrisp-quintus-source/common/comparisions.s
2026-06-16 17:17:07 <xentrac     > there's a Forth 2012 standard: https://forth-standard.org/
2026-06-16 17:17:24 <xentrac     > which is mostly backward compatible with ANSI Forth
2026-06-16 17:18:42 <xentrac     > dunno, bjorkintosh, what kind of thing are you interested in?
2026-06-16 17:18:53 <xentrac     > (in the context of Forth)
2026-06-16 17:20:11 <bjorkintosh > xentrac: mostly just a fan. been dabbling with ps lately (as you know, I think I mentioned it before elsewhere).
2026-06-16 17:20:32 <iv4nshm4k0v > I suppose I'd have to look at the tutorial, but I'm frankly not sure whether the idea of using Forth on "21st-century platforms" /at large/ is quite viable.  I think we /need/ more Forth-friendly platforms in the "21st century," but to me, "thinking Forth" is kinda incompatible with "using Big Browsers, DEs, GPUs, LLMs, etc." - including as platforms.
2026-06-16 17:21:05 <xentrac     > one of my standard pet peeves is equating PostScript to Forth :-)
2026-06-16 17:21:09 <bjorkintosh > and I have quite a few books on forth. the most intriguing of which is scientific forth by julian noble.
2026-06-16 17:21:18 <bjorkintosh > xentrac: that's okay.
2026-06-16 17:21:27 <lofty       > we need a webassembly forth clearly /j
2026-06-16 17:21:41 <xentrac     > my standard response is that PS is more like Lisp than it is like Forth
2026-06-16 17:21:46 <bjorkintosh > https://dl.acm.org/doi/pdf/10.1145/122630.127247
2026-06-16 17:21:50 <xentrac     > wasm is a challenging platform for compilation
2026-06-16 17:22:57 <xentrac     > this is a great article, thanks!
2026-06-16 17:23:12 <bjorkintosh > xentrac: ps and forth are clearly more alike than not. corvids, not robins.
2026-06-16 17:23:46 <xentrac     > bjorkintosh: I think it's more like dolphins and sharks
2026-06-16 17:24:03 <bjorkintosh > sure. they both live in water and intimidate everyone.
2026-06-16 17:24:07 <xentrac     > they both have that dorsal fin, so people sometimes confuse them
2026-06-16 17:26:19 <bjorkintosh > Northern Conservative Baptist Great Lakes Region differences.
2026-06-16 17:26:44 <xentrac     > more like Buddhists vs. Baptists
2026-06-16 17:27:00 <xentrac     > Mitch Bradely btw wrote OpenBoot/OpenFirmware
2026-06-16 17:27:04 <xentrac     > *Bradley
2026-06-16 17:27:04 <iv4nshm4k0v > lofty: WebAssembly is only supported by three-or-so Big Browsers.  Such an application wouldn't be usable to, say, blind people - who (I have it on a good authority) cannot use GUIs and have to resort to using a CLI browser (i. e., edbrowse) to interact with websites and webapps.
2026-06-16 17:27:22 <bjorkintosh > ultimately, lisp, forth and ps are all inspired by Łukasiewicz.
2026-06-16 17:27:38 <bjorkintosh > same grandmother, if you like.
2026-06-16 17:28:26 <xentrac     > yes, at that level all programming languages are closely related
2026-06-16 17:28:43 <bjorkintosh > not entirely.
2026-06-16 17:28:44 <xentrac     > Chuck Moore learned Lisp at MIT from McCarthy
2026-06-16 17:28:57 <bjorkintosh > polish notation, vs reverse polish notation.
2026-06-16 17:29:12 <bjorkintosh > the 'polish' part is what I'm emphasizing as the relevant connection.
2026-06-16 17:29:26 <xentrac     > PostScript is a dynamically-typed, garbage-collected programming language with first-class functions, built-in hash tables, a symbol type, and dynamic scoping.  it goes so far as to use higher-order functions, like Smalltalk, instead of having built-in control structures
2026-06-16 17:30:14 <xentrac     > Forth is an untyped, statically-scoped language with not just no garbage collection but normally no heap
2026-06-16 17:30:40 <lofty       > iv4nshm4k0v: accessibility is a very important thing to me, however I will point out that screen readers such as JAWS exist for GUIs and have strong integration with web browsers. but webassembly can be used outside of a browser in CLI form through WASI and hosts that support it like wasmtime.
2026-06-16 17:30:41 <bjorkintosh > but they both say 2 3 + instead of 2 + 3 :-)
2026-06-16 17:30:43 <xentrac     > these aspects are much more important than their syntactic similarity, which is pretty superficial
2026-06-16 17:31:01 <xentrac     > well, in PostScript you actually say 2 3 add
2026-06-16 17:31:31 <xentrac     > but that's an even more superficial difference
2026-06-16 17:32:34 <bjorkintosh > sure? /+ {add} def
2026-06-16 17:33:14 <xentrac     > yeah, you can do that --- but you can also write an infix parser in either language that processes your input stream
2026-06-16 17:33:27 <xentrac     > PostScript is homoiconic; standard Forth isn't, though, for example, indirect-threaded Forths are
2026-06-16 17:33:52 <lofty       > (accessibility is important to me because I have a disability of my own, but I'm "lucky" in that it's not necessarily a visible disability)
2026-06-16 17:34:00 <bjorkintosh > absolutely, in the end it's all just bits. 1, 0, and a handful of logical and arithmetic operations.
2026-06-16 17:34:19 <xentrac     > lofty: that can be harder rather than easier
2026-06-16 17:35:46 <iv4nshm4k0v > lofty: The discussions I saw at #edbrowse suggest that while screen readers are valuable tools for people with impaired vision, they still require at least /some/ eyesight to control the GUI browser.  A person who cannot discern GUI elements on screen by sight cannot use GUI browser, with or without a screenreader.
2026-06-16 17:37:01 <iv4nshm4k0v > By contrast, a CLI browser can be controlled by keyboard and a braille display.
2026-06-16 17:37:26 <lofty       > xentrac: being mute is a topic that is very hard to talk about :p
2026-06-16 17:39:04 <xentrac     > lofty: heh
2026-06-16 17:39:21 <xentrac     > anyway, fundamentally my argument is that semantics matter a lot more than syntax, and PostScript and Forth almost only share syntax
2026-06-16 17:39:56 <bjorkintosh > xentrac: that's all okay.
2026-06-16 17:39:59 <bjorkintosh > it's just for fun.
2026-06-16 17:40:16 <bjorkintosh > there are 1001 details to make the eyes bleed in every single thing.
2026-06-16 17:40:17 <iv4nshm4k0v > This channel's TOPIC suggests that a language has to "have two (or more) stacks" to be considered a Forth.
2026-06-16 17:40:36 <xentrac     > yeah, I'm not going to declare you anathema or anything, bjorkintosh :-)
2026-06-16 17:40:47 <iv4nshm4k0v > (I don't suppose that's something PostScript has, right?)
2026-06-16 17:40:57 <xentrac     > but I don't agree with your implicit assumption that semantics are a detail!
2026-06-16 17:41:07 <xentrac     > s/assump/asser/
2026-06-16 17:41:38 <lofty       > iv4nshm4k0v: yes, of course; accessibility is something that should be considered as a whole, and no one solution fits everyone.
2026-06-16 17:42:10 <lofty       > Imagine how it feels to try to book a taxi and the automated phone system asks me to speak my destination
2026-06-16 17:42:26 <bjorkintosh > iv4nshm4k0v: ps has 3.
2026-06-16 17:42:58 <bjorkintosh > xentrac: semantics _do_ matter, but not immediately to me.
2026-06-16 17:43:13 <bjorkintosh > it's the damned de{vil,tails}~~
2026-06-16 17:43:59 <bjorkintosh > digits are well covered by 0 and 1. what it means depends on who's asking no?
2026-06-16 17:44:01 <bjorkintosh > semantics...
2026-06-16 17:45:17 <xentrac     > PS has an arbitrary number of stacks ;)
2026-06-16 17:45:44 <xentrac     > lofty: Uber must have been a relief
2026-06-16 17:48:21 <lofty       > Trying to get a bus driver to understand a stop from Google Maps was also an experience
2026-06-16 19:11:16 <oak         > -1 on making jokes about people with disabilities
2026-06-16 19:11:54 <lofty       > I think I am allowed to make jokes about my own disabilities
2026-06-16 20:10:16 <xentrac     > I agree.  but I was afraid to laugh at them!
2026-06-16 20:10:30 <oak         > lofty: I agree. I misunderstood that you yourself are mute. My apologies, lofty.
2026-06-16 20:10:55 <lofty       > it's okay ^^;;
2026-06-16 20:11:30 <lofty       > xentrac: I've got a list of jokes about my mutism, but I've been keeping quiet about them.
2026-06-16 20:12:10 <oak         > >__<
2026-06-16 20:12:25 <lofty       > :3
2026-06-16 20:13:46 <xentrac     > heh
2026-06-16 20:17:26 <bjorkintosh > it's alright lofty. people talk too much.
2026-06-16 20:35:48 <oak         > Has anyone else struggled with keeping track of the stack? I'm ok with expressions like "4 5 +" or even "500 6 13 * -" because I just see backwards s-expressions and everything is laid out. But dang, when I start to see SWAPs and OVERs and R>s or even just word definitions where I feel like I'm required to keep the stack in my head.. I find it quite stressful. I'm really curious what it's like for
2026-06-16 20:35:50 <oak         > others and what's helped you.
2026-06-16 20:36:20 <lofty       > it is perfectly okay to put comments about the contents of the stack :p
2026-06-16 20:36:48 <bjorkintosh > comments are a rather lofty ideal.
2026-06-16 20:38:25 <lofty       > I am increasingly finding that my code is becoming "maximum of three on the parameter stack, maximum of one on the return stack", and if I'm going beyond that perhaps I should rethink the function and its context
2026-06-16 20:39:01 <bjorkintosh > driving a manual.
2026-06-16 20:39:54 <bjorkintosh > how to drive a manual: grab the nearest published manual to you, and make motorcar noises while moving it about like a steering wheel.
2026-06-16 20:39:56 <bjorkintosh > voila.
2026-06-16 20:41:01 <lofty       > um, as an example from my Forth chess program demo, my Rust instincts told me to pass the current position around as a parameter, which is reasonable in the context of a big multi-thread chess program, but in a single-thread demo, the position can just be a global variable that I access when I need it.
2026-06-16 20:41:24 <lofty       > and that's one less thing to juggle on the parameter stack.
2026-06-16 20:42:40 <lofty       > and likewise, when making a move, I need to reference the move often, but it's got to be a parameter. but I can "R>" it, and then recall it with "R@".
2026-06-16 20:44:10 <lofty       > I think that function would be a lot messier if I had to juggle it inside the parameter stack alone.
2026-06-16 20:49:20 <xentrac     > oak: yes, keeping track of the stack is a huge pitfall, especially for newcomers.  I explained what helped me in https://news.ycombinator.com/item?id=33264506
2026-06-16 20:49:47 <xentrac     > basically start by never using swap and over and r> and rot
2026-06-16 20:50:49 <xentrac     > briefly, though I explain this more at the above link, the way you avoid having more than three things on the parameter stack (a good idea!) is to store the other things in variables or values
2026-06-16 20:52:09 <xentrac     > with respect to multithreading, Forth has thread-local variables too.  they're called "user variables" because originally one of the reasons Forth was multithreaded was to support multiple simultaneous users
2026-06-16 20:52:12 <oak         > Mmm, that makes sense. It goes against a lot of my past learnings that "global variables = bad" and to keep data as local as possible.
2026-06-16 20:52:40 <xentrac     > yes, that's why it's a huge pitfall
2026-06-16 20:52:58 <bjorkintosh > oak: for small systems, it's not so bad.
2026-06-16 20:53:12 <bjorkintosh > for LARGE systems, it can be a goddamned nightmare.
2026-06-16 20:53:17 <xentrac     > well, no
2026-06-16 20:53:42 <xentrac     > there are a lot of reasons that global variables are bad, but they don't apply to Forth VARIABLEs
2026-06-16 20:54:00 <oak         > Why is that?
2026-06-16 20:55:09 <xentrac     > the main reasons are unintentional sharing and re-entrancy, and re-entrancy can be divided into recursion and concurrency such as multithreading
2026-06-16 20:58:08 <xentrac     > unintentional sharing is where you have two subroutines that both have a variable called "x", so when one of them assigns to it, the other one's value gets unintentionally overwritten
2026-06-16 20:59:15 <xentrac     > Forth's scoping prevents that from happening; if you say variable x  : inc1 x @ 1+ dup x ! ;  variable x  : dec1 x @ 1 - dup x ! ; then the two subroutines have two different variables named x
2026-06-16 21:00:47 <bjorkintosh > I did not know that.
2026-06-16 21:00:47 <lofty       > (variable shadowing considered useful)
2026-06-16 21:01:10 <xentrac     > recursion is relatively hard to run into unintentionally in Forth.  you generally have to use either defer or recurse, and so in either case you are hyper-aware that you are writing a recursive subroutine
2026-06-16 21:01:52 <xentrac     > so if it's going to use some local variable after it recurses, it needs to explicitly save and restore it from the stack.  something like x @ recurse x !
2026-06-16 21:02:15 <xentrac     > which is a little annoying but not really a big deal
2026-06-16 21:02:39 <xentrac     > as for concurrency, as I said, you can use thread-local ("user") variables
2026-06-16 21:03:44 <lofty       > this is very educational, thank you
2026-06-16 21:04:09 <lofty       > honestly "variable" seemed a bit strange to me, but I think I understand the intended usecase now
2026-06-16 21:04:26 <xentrac     > in addition to variable shadowing, Forth also has a module system that lets you put the variables for different parts of your program into different namespaces; the old name for these is "vocabularies" but ANS Forth calls them "wordlists" instead
2026-06-16 21:05:02 <bjorkintosh > let's just have xentrac talk about forth for a bit.
2026-06-16 21:05:13 <bjorkintosh > xentrac: I'm taking notes. this is useful. thank you.
2026-06-16 21:05:14 <xentrac     > 
ACTION blushes

2026-06-16 21:05:25 <lofty       > (...I admit I am unsure how to implement wordlists in Forth)
2026-06-16 21:05:34 <bjorkintosh > perhaps he might say.
2026-06-16 21:05:39 <lofty       > perhaps!
2026-06-16 21:06:04 <bjorkintosh > 'cause I'd never really thought of Forth the way he describes in his post from orange reddit: it's an embedded _os_ and language!
2026-06-16 21:06:11 <bjorkintosh > that's pretty powerful.
2026-06-16 21:06:33 <xentrac     > and debugger!
2026-06-16 21:06:54 <xentrac     > lofty: yeah, variable hails from a time period when it was debated whether it was worthwhile for programming languages to support recursion, since that meant all their local variables accesses would have to be indexed off some kind of frame pointer, making them slower
2026-06-16 21:07:02 <oak         > I'm reading the article you (xentrac) linked to...
2026-06-16 21:07:06 <xentrac     > Fortran didn't support recursion until Fortran 90
2026-06-16 21:07:07 <bjorkintosh > xentrac: gotta spit out your sources, please. so that i can do some homework.
2026-06-16 21:07:24 <xentrac     > bjorkintosh: what do you mean?
2026-06-16 21:07:39 <bjorkintosh > well there are a few books about Forth out there.
2026-06-16 21:07:41 <lofty       > I think bjorkintosh wants to be pointed at more things to read about this stuff
2026-06-16 21:07:49 <bjorkintosh > and articles, of course.
2026-06-16 21:07:53 <bjorkintosh > ^ what lofty said.
2026-06-16 21:08:13 <bjorkintosh > now, I love tcl. anyone who can talk about Forth in terms of tcl has my attention, naturally.
2026-06-16 21:08:51 <xentrac     > lofty: I haven't ever implemented wordlists, but basically the technique is that each wordlist is a linked list in the dictionary, I think
2026-06-16 21:09:08 <xentrac     > or potentially a hash table with 8 or 16 linked lists or something
2026-06-16 21:09:30 <xentrac     > bjorkintosh: my bookmarks about Forth are in https://canonical.org/~kragen/human-folly/tag/forth.html
2026-06-16 21:10:53 <lofty       > I get a self-signed cert error there
2026-06-16 21:11:09 <lofty       > which is also two years out of date
2026-06-16 21:12:18 <xentrac     > oops sorry.  http://canonical.org/~kragen/human-folly/tag/forth.html
2026-06-16 21:13:03 <lofty       > I recognise more than a few names in this list. small world.
2026-06-16 21:13:04 <xentrac     > bjorkintosh: I think Tcl and Forth have a lot of advantages in common, although their disadvantages are mostly disjoint
2026-06-16 21:13:36 <bjorkintosh > writing tcl is probably the most fun I've had in any language so far.
2026-06-16 21:13:39 <bjorkintosh > it was joyous.
2026-06-16 21:13:50 <bjorkintosh > writing _in_ sorry.
2026-06-16 21:13:59 <bjorkintosh > I didn't create tcl. that's one Ousterhout, J.
2026-06-16 21:14:27 <lofty       > I have used Magic VLSI. it is. one of the pieces of software of all time.
2026-06-16 21:14:32 <oak         > I'm really interested in this "flow" concept and learning how to think this way.
2026-06-16 21:15:20 <bjorkintosh > oak: data flow?
2026-06-16 21:16:01 <oak         > bjorkintosh: as described in https://yosefk.com/blog/my-history-with-forth-stack-machines.html
2026-06-16 21:16:19 <oak         > I'm not sure how to summarize
2026-06-16 21:16:43 <bjorkintosh > oak: I thought you meant https://en.wikipedia.org/wiki/Lucid_(programming_language)
2026-06-16 21:18:51 <xentrac     > (it's probably worth explaining for those who don't know that Tcl originated as the scripting language for Magic VLSI, perhaps in revolted reaction to SPICE linking in csh when it needed a scripting language)
2026-06-16 21:19:36 <lofty       > oh yeah, I've used [NG]SPICE as well. somehow they made it worse by adding typing.
2026-06-16 21:20:43 <xentrac     > I think SPICE added csh before Magic added scriptability, and they were both Berkeley projects
2026-06-16 21:21:28 <oak         > ha ha, "This stack business? Just a tiny aspect of the matter. You have complicated expression graphs? Why do you have complicated expression graphs? The reason Forth the language doesn't have variables is because you can eliminate them, therefore they are junk, therefore you should eliminate them. What about those expressions in your Forth program? Junk, most likely. Delete!"
2026-06-16 21:21:42 <xentrac     > haha
2026-06-16 21:21:49 <xentrac     > well, it's nice when that's an option...
2026-06-16 21:21:59 <xentrac     > I don't think Tcl is a very good programming language, but it's sure better than csh
2026-06-16 21:22:13 <xentrac     > complicated expression graphs in Forth aren't any more difficult than in C
2026-06-16 21:22:20 <bjorkintosh > tcl is misunderstood.
2026-06-16 21:22:35 <bjorkintosh > it's the commonperson's lisp :-D
2026-06-16 21:22:44 <lofty       > (I've been in the hardware space for almost a decade at this point)
2026-06-16 21:23:29 <xentrac     > consider:
2026-06-16 21:23:31 <bjorkintosh > also, tcl is *dying*
2026-06-16 21:23:32 <xentrac     >   void **blocks = p->disc.malloc(initial_block_list_capacity * sizeof(*blocks), disc.userdata);
2026-06-16 21:23:40 <bjorkintosh > C?
2026-06-16 21:23:42 <bjorkintosh > 
ACTION flees.

2026-06-16 21:24:17 <xentrac     > that's just p disc initial_block_list_capacity @ blocksize * mydisc userdata malloc
2026-06-16 21:24:18 <lofty       > side note, xentrac, your explanation of "variable" means I should be able to simplify some of the...clumsiness of one of my functions
2026-06-16 21:24:23 <oak         > This article is making me think about how human brains differ, and it makes sense that this would extend to how different people think about programming and software, and why certain languages work for some folx but not others.
2026-06-16 21:24:58 <xentrac     > blocks ! (I forgot that part)
2026-06-16 21:25:13 <oak         > Last year I learned about aphantasia -- how something like 20% of people can't picture things in their head. I imagine Forth would be harder for them. I imagine even folx with phantasia have it to varying degrees.
2026-06-16 21:25:14 <bjorkintosh > oak: programmer as cognitive anthropologist aye?
2026-06-16 21:25:25 <xentrac     > you just put @ after your rvalue variable names, put operators after their operands instead of between them, and rewrite assignments x = y to y x !
2026-06-16 21:25:30 <lofty       > oak: hi.
2026-06-16 21:25:54 <bjorkintosh > oak: why? you can sketch/scribble.
2026-06-16 21:26:06 <xentrac     > I don't know if Tcl is dying?  I don't think anything that currently uses Tcl is going to stop doing so
2026-06-16 21:26:24 <lofty       > I think a lot of understanding Forth is about pattern recognition, to me.
2026-06-16 21:26:29 <bjorkintosh > xentrac: https://markroseman.com/tcl/dyingout.html
2026-06-16 21:26:31 <oak         > bjorkintosh: that's a lot more work than just being able to think about it. It's not about it being impossible, but about what works *well* or easily for different brains
2026-06-16 21:26:52 <xentrac     > oh, well, Tk is dying
2026-06-16 21:27:07 <bjorkintosh > oak: pen and paper are probably the most powerful tools each one of us have.
2026-06-16 21:28:01 <oak         > bjorkintosh: I think we're maybe talking about different things?
2026-06-16 21:28:12 <bjorkintosh > seeing one's thoughts?
2026-06-16 21:28:30 <oak         > I don't know what that means.
2026-06-16 21:28:44 <xentrac     > Tk was great before DHTML
2026-06-16 21:28:56 <lofty       > > how people can't picture things in their head.
2026-06-16 21:29:09 <lofty       > I think bjorkintosh is referring to this by "seeing one's thoughts"
2026-06-16 21:29:19 <bjorkintosh > exactly lofty.
2026-06-16 21:29:53 <oak         > bjorkintosh: Does it make sense that HAVING to write something out to work with it would be more work than someone who can just think it in a fraction of a second?
2026-06-16 21:31:05 <bjorkintosh > oak: I don't know. I have scores of writing instruments and paper and notebooks around me which I use quite regularly, even though I can picture things quite vividly in my mind and can barely draw stick figures.
2026-06-16 21:31:18 <lofty       > I would say I have aphantasia.
2026-06-16 21:31:18 <bjorkintosh > for me it's indispensable.
2026-06-16 21:31:37 <lofty       > if somebody asked me to picture something in my mind, I would not be able to do it.
2026-06-16 21:31:52 <bjorkintosh > how do you figure?
2026-06-16 21:32:12 <oak         > bjorkintosh: I'm not sure how else to explain that thinking a thought is less work than writing something down. ;)
2026-06-16 21:32:38 <bjorkintosh > oak: it is less work.
2026-06-16 21:32:49 <xentrac     > oak: it isn't always!  some thoughts take a lot more than a fraction of a second for me to think
2026-06-16 21:32:50 <bjorkintosh > we were after all born without writing instruments weren't we?
2026-06-16 21:33:00 <bjorkintosh > but it is HIGHLY limited for 99.9999999999% of people.
2026-06-16 21:33:05 <xentrac     > and can get *easier* when I write them down
2026-06-16 21:33:45 <oak         > The crux of what I was trying to express is that I could see different human neurologies resulting in different programming language preferences.
2026-06-16 21:33:50 <oak         > And aphantasia was an example.
2026-06-16 21:33:56 <lofty       > if you ask me to imagine, like, a beach, there is no mental image of that beach in my mind. but, mentally, beaches have sand, they have rocks; there's an ocean lapping at the shore. I have all the _pieces_ of the image, but not the image.
2026-06-16 21:34:05 <bjorkintosh > oak: it's there to save your life. you do not sit down to write a paper about the possible dangers of a viper in the jungle. you simple fucking run when you see one!
2026-06-16 21:34:31 <oak         > bjorkintosh: That's... not at all what I'm saying.
2026-06-16 21:34:38 <bjorkintosh > well then. you lost me.
2026-06-16 21:34:45 <bjorkintosh > I can't Imagine what you're talking about!
2026-06-16 21:34:54 <bjorkintosh > 
ACTION lacks the requisite fantasy.

2026-06-16 21:35:04 <oak         > Ok. :)
2026-06-16 21:36:16 <bjorkintosh > oakay
2026-06-16 21:39:27 <xentrac     > yeah, I think there are almost certainly people whose minds fit Forth better than mine :-)
2026-06-16 21:39:39 <lofty       > I will admit I am still kind of struggling with the lack of parens for expressions in Forth, but I am trying my best
2026-06-16 21:39:53 <lofty       > "position-enable-mask@   1 i lshift  and     0<>     to-square-enabled !"
2026-06-16 21:39:56 <bjorkintosh > lofty: that's the point of Polish Notation.
2026-06-16 21:40:05 <xentrac     > yeah, that helps a lot
2026-06-16 21:40:06 <bjorkintosh > it was to get rid of the ()s
2026-06-16 21:40:27 <xentrac     > bjorkintosh: IMHO that reduces readability
2026-06-16 21:40:43 <lofty       > yes, but my brain uses () to delimit expressions
2026-06-16 21:41:24 <xentrac     > when you have a b c d e that could mean e(d(c(b(a))) or e(a, c(d(b)) or e(a, b, c, d) or numerous other possibilities
2026-06-16 21:41:43 <xentrac     > the data flow is completely implicit
2026-06-16 21:41:59 <lofty       > "((position-enable-mask@   (1 i lshift)  and)     0<>)    to-square-enabled !"
2026-06-16 21:42:07 <xentrac     > right
2026-06-16 21:42:39 <xentrac     > so, as the reader, you have to discover the data flow
2026-06-16 21:42:55 <xentrac     > and hopefully the spacing helps, but the author could have gotten it wrong
2026-06-16 21:45:40 <lofty       > another thing I admit I struggle with is what the "right" way to write logical expressions is. you can write "x y z w and and and" or "x y and z and w and"; I don't know which is considered clearer.
2026-06-16 21:46:38 <oak         > lofty: intuitively, the latter feels clearer to me.
2026-06-16 21:47:03 <lofty       > I think I would definitely write the latter if I was breaking it up over multiple lines
2026-06-16 21:48:06 <xentrac     > I would tend toward the latter on the theory that it requires a shallower mental stack from the reader
2026-06-16 21:48:26 <oak         > I know another stack language (uxntal) that makes [ and ] purely visual/no-op characters, so you can do grouping in your code like "[x y and] z and".
2026-06-16 21:49:44 <oak         > xentrac: "shallower mental stack" -- that's a good way of describing it.
2026-06-16 21:50:00 <lofty       > also how dumb is it to ": <= > invert ;" ^^;;
2026-06-16 21:50:19 <oak         > With the expr that ends with "and and and" I feel like I need to be careful and count the identifiers to make sure it's all the parity I expect.
2026-06-16 21:50:48 <lofty       > oak: I think you mentioned you have familiarity with lisp, right?
2026-06-16 21:50:50 <oak         > lofty: I love cute little def'ns like that. :)
2026-06-16 21:50:58 <oak         > 
ACTION nods

2026-06-16 21:51:21 <lofty       > how does "(and x y z w)" look to you?
2026-06-16 21:51:51 <oak         > lofty: Honestly? Like a mental relief vs. the equivalent Forth, hehe
2026-06-16 21:51:58 <oak         > Very easy for my brain.
2026-06-16 21:52:17 <lofty       > sometimes I think of the horrors that come from Verilog
2026-06-16 21:52:26 <lofty       > "&{x, y, z, w}"
2026-06-16 21:54:34 <lofty       > (in no other language I have used does adding zero to an expression change the result...)
2026-06-16 21:55:38 <oak         > lofty: in JavaScipt, "[] + 0 = '0'" >:)
2026-06-16 21:55:50 <oak         > JavaScript*
2026-06-16 21:56:07 <oak         > and yes, that is the STRING "0" on the right
2026-06-16 21:57:19 <lofty       > You want to check if the expression "x + y" overflows, so you do "(x + y) >> 16" and the Verilog standard guarantees the result is always zero.
2026-06-16 21:57:44 <lofty       > *if the expression on 16-bit values
2026-06-16 21:59:28 <lofty       > because the intermediate expression "x + y" is calculated at 16-bit precision and thus "(x + y) >> 16" is a 0-bit precision value
2026-06-16 22:00:54 <lofty       > Another fun thing is that the "$signed()" operator is defined to sign-extend an expression. Unless it's inside a "?"/":" ternary expression, in which case it zero-extends instead
2026-06-16 22:05:21 <xentrac     > today I've been working through an interactive tutorial in Lean
2026-06-16 22:05:46 <xentrac     > one of the things I had to do was to prove that 0 + 0 = 0
2026-06-16 22:09:36 <oak         > I was looking at some Forth code that does division, and they use /MOD rather than / and throw away the remainder. Is /MOD faster or something?
2026-06-16 22:10:23 <lofty       > on x86 you get both division and remainder as a result of dividing. so, not faster, but also not slower.
2026-06-16 22:11:19 <bjorkintosh > xentrac: well? is it?
2026-06-16 22:12:30 <xentrac     > bjorkintosh: under the definition of addition in scope at the time, yes, it was, because one of the two axioms defining + in that context is that x + 0 = x
2026-06-16 22:12:43 <lofty       > (also I worry my variable names are too verbose, but, maybe it's more readable that way)
2026-06-16 22:14:28 <lofty       > https://gist.github.com/Ravenslofty/3d4bd96cfb5dbf6e3c902d8fe15d1c0a <--- kind of wish github gave side-by-side diff for gists; oh well
2026-06-16 22:14:59 <xentrac     > oak: I think the only reason I would do that is if I hadn't defined /
2026-06-16 22:15:54 <xentrac     > it *might* be slower depending on the Forth.  and there might be a Forth where it returns a different answer than / if the arguments aren't both positive
2026-06-16 22:16:01 <xentrac     > but that's all I can think of