simon/post-scarcity
1
0
Fork 0
Code Issues 18 Pull requests Projects Releases Packages Wiki Activity Actions

Closes #18. Change to char32_t everywhere; builds fine, behaviour as before.

Browse source
This commit is contained in:
Simon Brooke 2026-04-20 12:10:38 +01:00
parent 812a1be7d9
commit c59825d7fe
33 changed files with 116 additions and 76 deletions
Download patch file Download diff file Expand all files Collapse all files

26
docs/State-of-play.md
View file

@ -1,12 +1,32 @@
# State of Play
## 20260420
Still on side projects, but those side-projects are giving me thinking time;
and over the past few days I've logged four issues that I've tagged
[`Architecture change`](https://git.journeyman.cc/simon/post-scarcity/issues?q=&type=all&state=open&labels=15&milestone=0&assignee=0&poster=0).
These are:
* 17: [Add readtables; implement quote and keyword through readtables.](https://git.journeyman.cc/simon/post-scarcity/issues/17)
* 18: [Consider converting from `char32_t` to `char32_t`, everywhere.](https://git.journeyman.cc/simon/post-scarcity/issues/18)
* 20: [Environment in stack frame.](https://git.journeyman.cc/simon/post-scarcity/issues/20)
* 21: [Temporary objects in a function must be bound to a locals slot in the stack frame](https://git.journeyman.cc/simon/post-scarcity/issues/21)
These, especially the last, mean a fundamental change not only to the Lisp calling convention, but also to everything which may create objects — even if they're never expected to be called directly from Lisp. Generally, **every** such thing must be called with the standard Lisp calling convention (and so potentially could be called directly from Lisp), except for those very rare things where calling them with the standard calling convention would cause a runaway infinite recursion (the obvious ones are the constructors for `stack_frame` and `cons`, but there may be others); and the Lisp calling convention has to change. Which means a lot of things which have already been written for `0.1.0` have to change.
So I have this morning started a new feature branch, `feature/reengineering-17-21`, to work on these four issues together; and I think the first thing to do is to audit the existing code for functions that are affected by these changes (I mean: *every* Lisp-callable function is affected by 20, but apart from that). This may also resolve the `[MANAGED_POINTER_ONLY](https://git.journeyman.cc/simon/post-scarcity/src/commit/812a1be7d9eb97c25aa07477eb71605b1af93397/src/c/payloads/function.h#L16)` issue (see [20260415](#20260415)). I *may* leave that in as a compile time switch because passing the unmanaged pointer is certainly a performance optimisation, but it will make writing the compiler a bit harder.
I'm not ignoring the fact that a lot of stuff in `0.1.0` is still fundamentally broken, and the REPL still doesn't work; but getting the calling convention right at this point is still the right thing to do, and won't make any of those problems worse. Indeed, it may resolve some of them.
I think this week is going to be mostly a thinking week — partly because the weather forecast is unusually benign, and it would be sensible get some outdoor work done.
## 20260415
OK, I have been diverted down a side-project on a side-project. I decided
that since Post Scarcity definitely needs a compiler, I should learn to write
a compiler, and so I should start by writing one for a simpler Lisp than Post
Scarcity. So I started to write
[one in Guile Scheme for Beowulf](https://git.journeyman.cc/simon/naegling).
Scarcity. So I started to write [one in Guile Scheme for Beowulf](https://git.journeyman.cc/simon/naegling).
This is started but a long way from finished. I'm also not very enamoured of
Guile Scheme, and am starting to wonder whether in fact I should be writing
if in [Beowulf](https://git.journeyman.cc/simon/beowulf) for Beowulf.
@ -75,7 +95,7 @@ managed pointer is cheap, it isn't free.
But it's worth thinking about.
## 20260331
Substrate layer `print` is written; all the building blocks for substrate