Substantial work on read-list, not yet fully working.

docs/State-of-play.md

@@ -1,5 +1,30 @@
 # State of Play
 
+## 20260506
+
+A day of some achievements. I got `dump` working, although not perfectly, and this helped me diagnose the problem with `equal`, and hence with `assoc`; these are now fixed, and consequently `eval_symbol` now works.
+
+However the problem was that you cannot mix `wchar_t` and `char32_t`: the same character in the two encodings does not have the same value. So I've reversed the [issue 18](https://git.journeyman.cc/simon/post-scarcity/issues/18) fix.
+
+I've started work on reading lists, and although it doesn't completely work yet, it's close.
+
+However!
+
+### Unclean objects
+
+It's been obvious for some time that freshly allocated objects are not always clean. 
+
+I'm seeing entries like these in the logs:
+
+```
+WARNING: Count of 2 in newly allocated object at 3, 5456, should be 0
+WARNING: Count of 4 in newly allocated object at 1, 0, should be 0
+WARNING: Count of 2 in newly allocated object at 4, 5456, should be 0
+WARNING: Count of 8 in newly allocated object at 1, 0, should be 0
+```
+
+What's worse than dirty counts is dirty pointers, and we're seeing those, too. This is particularly dangerous for stack frames, but it isn't good for anything. I have a faint worry — I don't *think* this is the problem — that I might be miscalculating offsets, and have objects interfering with one another. I am going to need to have a thorough go at object sanitation, both when objects are freed, and when they're reallocated. In good news, garbage collection of stack frames really is working — but nothing else is yet getting garbage collected.
+
 ## 20260505
 
 ### The stack frame corruption(?) bug