> First off, this version makes all state-variable names are declared - they cannot be made-up on the fly at runtime.
This is the same with SRFI 159. All state variables are introduced by syntax.
Ok, yes.
> 1) the state object is just an eq-hashtable. A fresh state object is always empty. Default values for state-variables are inserted as needed.
>
> 2) the implementation must provide a function (identifier->eqobj #'id) which returns a unique key associated with the identifier's binding (or non-binding). Two identifiers produce the same eq? key IFF then they match hygienically, and are free-identifier=?. These keys are the runtime keys used to store values in the state. All state-variables are bound.
What you call a "function" has to be syntax, doesn't it?
No. But the #' thing certainly needs to be. So, yes, if it were written (identifier->eqobj foo), then it would have to be syntax.
What do you mean by "match hygienically"?
Match as in literal-matching in syntax-rules. I was intentionally being redundant.
How do you handle the case of unbound identifiers a and b? When is
(eq? (identifier->eqobj #'a) (identifier->eqobj #'b))?
identifier->eqobj for an unbound identifier returns the symbol itself for consistency with free-identifier=?. This is not relevant to my alternative monad idea because it is only ever called on bound identifiers.
Is fieldspec to be read as an identifier and not as a raw symbol?
Yes.
However, this won't work in a robust way (without surprises):
(fn (col)
(let loop ((col col) (foo 0))
(if (zero? col)
(each foo (fn (col) ...))
(loop (- col 1) (+ foo col)))))
That's the motivation for the strong error detection. The (fn (col) on the 4th line, when expanding will detect that col is not a state-variable and produce a syntax error.
What about (fn ((col col)) ...)?
I didn't bother do anything special there, but it would be straightforward to 1) add detection of this case and treat it like the single-id case, and 2) if the first id is a state-variable and is different from the second state-variable, generate a syntax-error.
identifier->eqobj seems to be much more problematic.
No doubt. Just an experiment to explore the space and trigger more ideas.
-jim