From the multiprocessing point of view, writing to a static binding is essentially writing to a structure slot, which should be atomic on all implementations;
If a programmer creates a macro that wraps static-let and fails to document that the binding it creates is going to be static/shared between invocations, I don't think it's the responsibility of Serapeum to try and fix that issue for them;
macroexpand and slime-macrostep are both going to show that a static-let is used somewhere,
Semantics of writing to a non-constant load-time-value object are well-defined in standard CL so there's no possibility of a conformance issue,
(static-bind ((#1=#:x (list (make-large-object)))) (symbol-macrolet ((x (car #1#))) (setf x (make-another-large-object)))) easily defeats the current setf safeguard.
I think it would be more lispy in spirit to empower and trust the programmer, rather than try to prevent them from doing things they think they have a valid use case for. And, IMO, if people find use cases for writing to static local variables in C, they're gonna find those for CL.
(Moved from #108)
https://github.com/ruricolist/serapeum/commit/4781c27c2eb491b1c68a15178421b039103ee578 caused the static bindings created by
static-letandstatic-let*to become immutable. I don't think there is a technological reason to do that, or much to worry about them being mutable from a position of Serapeum maintainer.static-letand fails to document that the binding it creates is going to be static/shared between invocations, I don't think it's the responsibility of Serapeum to try and fix that issue for them;macroexpandandslime-macrostepare both going to show that astatic-letis used somewhere,load-time-valueobject are well-defined in standard CL so there's no possibility of a conformance issue,(static-bind ((#1=#:x (list (make-large-object)))) (symbol-macrolet ((x (car #1#))) (setf x (make-another-large-object))))easily defeats the currentsetfsafeguard.I think it would be more lispy in spirit to empower and trust the programmer, rather than try to prevent them from doing things they think they have a valid use case for. And, IMO, if people find use cases for writing to static local variables in C, they're gonna find those for CL.