Very interesting! For those who do not pay too much attention to Forth, the forth standard [0] still sees fairly regular updates. GForth, the implementation that I've spent the most time with, gets several commits per week, so it's not dead, though I suspect that it's a small handful of individuals who use it frequently that are keeping it alive and not widespread use.
Forth is absolutely worth learning, if for no other reason than understanding how stack-based interpreters work. The CPython VM, as an example, behaves similar in some respects to the average Forth program.
There's definitely better examples out there, but here[1] is an implementation of Mage the Awakening 2e's (tabletop game) spellcasting system in Forth that I wrote to help with playing awile ago.
It's also important to point out that a forth standard probably helps a few of the commercial vendors keep some level of interoperability, but in general, the hobbyist community (I would guess the bulk of forth users today) ignores the standard almost entirely and just implements their own forth (commonly a new one for each project).
The old saying is "if you've seen one forth, then you've seen one forth". It isn't a language like Python, but more like a language philosophy.
The creator of forth (chuck Moore) wasn't a fan of standards and felt they led to bloat. He was uniquely lucky and gifted to where he would figure out the minimum implementation of both hardware + software to solve a problem and by hardware...I mean he designed his own chips. So at the end of the day, he had a holistic tool where the hardware and software were designed together to solve a specific problem. He wouldn't implement anything he didn't need. It's a fascinating process that I would guess wouldn't work for 99.999% of people as most of us aren't at that level of knowledge/efficiency.
I've always suspected that most people learn forth by implementing one, rather than by picking an existing implemntation and using it for something real/significant.
This is too much to bear and I had to create an account for this!
Might I interest you in the opposite? Sort of a Lisp implemented in Forth that can compile Lisp functions to native code, all of this in less than 500 lines of Dusk code.
Condolences on finally opening an HN account. I greatly appreciate your work even though I disagree with much of it. DuskOS in particular seems excellent.
> What's the most interesting program you've written in comp/lisp?
None. I wrote comp/lisp because my lack of Lisp knowledge seemed to me like a liability as I invest more and more time in Forth. I had nothing I felt like writing in Lisp, so I thought it would be fun to implement one.
While I can't call myself a Lisp programmer, I think I can say now I have an idea of what it's about. It didn't grow on me, so I leave it aside for now. Maybe I'll come back to it later.
> I infer that you are just using dynamic scoping, thus ruling out both upward funargs and tail-call elimination?
Tail-call elimination is possible with my implementation within the same function, but it's not "natural". I'm not sure of what it would take to have it like we see them in other lisps, or if it's possible at all. It's been a while since I swam in that pond, details aren't fresh in my mind.
As for scoping, I'm unfamiliar with the theory. I don't think it's what we call "lexical scoping" because variable names have very little meaning in the compilation process. It's eliminated very early and only "compile time Parameter Stack offset" is kept in the AST.
I don't know what you mean by "upward funargs", but if it's to access arguments from outer scope, yes it's possible. That's exactly the point of the last link you pointed to: lambda generation. A call to a closure generates a lambda which has its outer scope "injected" to PS.
Thanks for the excellent work you're doing! It's (extremely) high on my list of things-to-do if I ever get more time for learning and progressing my very rudimentary programming knowledge.
This is excellent as well. I don't really jive with the Collapsnik aspect but I absolutely love powerful systems that can run in constrained environments.
Thanks for sharing, I'll be diving into this for a while
I came in to this thread to ask if anyone had done this, given an intuition that it seems like a fairly natural path to bootstrapping lisp on metal. Didn't even have to ask!
>"Open" here was a popular term back in the day and bunch of companies used it .. sorta like AI, LLM, and blockchain.
nah. what you are describing is Open in the present day, like OpenAI.
back in the day it meant "open standards, allowing cooperation between secretive competitors". IBM and Digital could both implement to an open standard instead of their traditional proprietary so their devices would interoperate.
This type of openness is what Microsoft liked to "embrace, extend, extinguish", meaning "we'll get kudos joining the interoperating consortium, we'll look cutting edge by adding features which would make us not actually interoperate but are useful so people will adopt them, then we will have killed off this threat to our monopoly"
in that same period of time, open source started to be called that because what was open was the source.
I'm sure if they weren't incentivised by the certainty of creating a legal minefield in the future then this technology would never have been created and we'd be sitting at home banging sticks together.
I recently posted a paper on the Permacomputing Aesthetic (https://news.ycombinator.com/item?id=41818119) which argues there is a counter current of developers that want to go against the maximalist world of computing and rediscover programming as art on constrained systems. In this world, where we do not idolize the large teams of code monkeys, languages like Forth can see a resurgence. Forth is a bad language for a team of people of dubious and different skillset, but in the hands of a single person it is the most moldable environment, even moreso than Lisp.
I have been designing some sort of "persistent" Forth OS, that boots into an interpreter and persists your defined words across sessions and reboots, so you can incrementally build your own personal computer from scratch.
I doubt it ever will. There's still pockets on the internet and a few tireless maintainers, but I doubt it'll ever see much of a resurgence. It's just too different. Maybe during "bring-up" of embedded systems, but even that I think is mostly on the way out sadly.
I don't see standard Forth going anywhere; same for Common Lisp, Scheme & Smalltalk.
They had a good run, and they're still fun to play around with and useful for teaching and stealing ideas from. But the world has moved on in too many ways.
There's still a lot of ground to explore between Forth and Lisp though, and plenty of modern ideas to steal from scripting languages.
The use of CODE/;CODE/;ENCODE for defining words in lisp is great. I can see myself using this a good amount especially if I can get it playing well with Tk either through the FFI or lTk/nodgui.
It sounds like it would preclude doing any actual work with LispWorks, yes. But maybe someone at Harlequin will take interest and fix whatever the LispWorks bug is, or in the unlikely case that it's a CL-Forth bug, propose a fix. (It could be a CL-Forth bug, because Common Lisp allows you to turn off safety.) It doesn't preclude doing any actual work with CL-Forth, though, because you can use better Common Lisps.
Readit News
Forth is absolutely worth learning, if for no other reason than understanding how stack-based interpreters work. The CPython VM, as an example, behaves similar in some respects to the average Forth program.
There's definitely better examples out there, but here[1] is an implementation of Mage the Awakening 2e's (tabletop game) spellcasting system in Forth that I wrote to help with playing awile ago.
[0]: https://forth-standard.org/
[1]: https://git.sr.ht/~chiefnoah/spellbook/tree
The old saying is "if you've seen one forth, then you've seen one forth". It isn't a language like Python, but more like a language philosophy.
The creator of forth (chuck Moore) wasn't a fan of standards and felt they led to bloat. He was uniquely lucky and gifted to where he would figure out the minimum implementation of both hardware + software to solve a problem and by hardware...I mean he designed his own chips. So at the end of the day, he had a holistic tool where the hardware and software were designed together to solve a specific problem. He wouldn't implement anything he didn't need. It's a fascinating process that I would guess wouldn't work for 99.999% of people as most of us aren't at that level of knowledge/efficiency.
Forth and Lisp are both super freaking cool.
Might I interest you in the opposite? Sort of a Lisp implemented in Forth that can compile Lisp functions to native code, all of this in less than 500 lines of Dusk code.
https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/doc/co...http://duskos.org/
I hadn't looked at comp/lisp before. It definitely looks like a real Lisp to me. In https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/mem/co... I see that you have dynamic typing, implemented in assembly, and from https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/mem/co... to line 70 you have a garbage collector. From https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/comp/l... I see you have closures, but I'm not sure how memory allocation for their captured variables works; from https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/comp/l... I infer that you are just using dynamic scoping, thus ruling out both upward funargs and tail-call elimination?
What's the most interesting program you've written in comp/lisp?
None. I wrote comp/lisp because my lack of Lisp knowledge seemed to me like a liability as I invest more and more time in Forth. I had nothing I felt like writing in Lisp, so I thought it would be fun to implement one.
While I can't call myself a Lisp programmer, I think I can say now I have an idea of what it's about. It didn't grow on me, so I leave it aside for now. Maybe I'll come back to it later.
> I infer that you are just using dynamic scoping, thus ruling out both upward funargs and tail-call elimination?
Tail-call elimination is possible with my implementation within the same function, but it's not "natural". I'm not sure of what it would take to have it like we see them in other lisps, or if it's possible at all. It's been a while since I swam in that pond, details aren't fresh in my mind.
As for scoping, I'm unfamiliar with the theory. I don't think it's what we call "lexical scoping" because variable names have very little meaning in the compilation process. It's eliminated very early and only "compile time Parameter Stack offset" is kept in the AST.
I don't know what you mean by "upward funargs", but if it's to access arguments from outer scope, yes it's possible. That's exactly the point of the last link you pointed to: lambda generation. A call to a closure generates a lambda which has its outer scope "injected" to PS.
Thanks for sharing, I'll be diving into this for a while
"Open" here was a popular term back in the day and bunch of companies used it .. sorta like AI, LLM, and blockchain.
nah. what you are describing is Open in the present day, like OpenAI.
back in the day it meant "open standards, allowing cooperation between secretive competitors". IBM and Digital could both implement to an open standard instead of their traditional proprietary so their devices would interoperate.
This type of openness is what Microsoft liked to "embrace, extend, extinguish", meaning "we'll get kudos joining the interoperating consortium, we'll look cutting edge by adding features which would make us not actually interoperate but are useful so people will adopt them, then we will have killed off this threat to our monopoly"
in that same period of time, open source started to be called that because what was open was the source.
https://www.youtube.com/watch?v=rRbY3TMUcgQ
https://github.com/codr7/cl-scrl
https://github.com/codr7/snabel
https://github.com/codr7/fipl
https://github.com/codr7/lila
It is so great tool, even just for stretching your brain cells..
I have been designing some sort of "persistent" Forth OS, that boots into an interpreter and persists your defined words across sessions and reboots, so you can incrementally build your own personal computer from scratch.
How exactly?
They had a good run, and they're still fun to play around with and useful for teaching and stealing ideas from. But the world has moved on in too many ways.
There's still a lot of ground to explore between Forth and Lisp though, and plenty of modern ideas to steal from scripting languages.
(not its standard sure)
wouldn’t this normally preclude doing any actual work with it?
Most people playing around with this will be using sbcl though. It's overwhelmingly the most popular free common lisp system.