* Relationship between SRFI 165 and SRFI 159
SRFI 165 is both separating from SRFI 159 the part of SRFI 159's API
that deals with the environment monad into a reusable library as well
as extending this API in several ways and specifying its semantics
more precisely:
(1) Underlying the semantics of SRFI 159 is the environment monad. A
formatter of SRFI 159 is nothing but a monadic value of this monad.
I think you mean monadic function.
[There is a slight error in the text of SRFI 159, which states that a
formatter is an environment monad.]
It says "essentially a monad" in intentionally hand-wavy terms.
I didn't want to overcomplicate the SRFI, nor restrict it in any way.
I think SRFI 165 looks useful in its own right, but would want to see
wider adoption and usage before wanting to define the formatters
in terms of it. I could probably be convinced, but this seems too new
and too late for the Tangerine edition. If we don't use monads for
anything else in the large language it seems a premature abstraction.
[Note there's an alternate implementation of SRFI 159 that uses only parameters,
without passing any explicit state, which is arguably not an env monad.]
(2) Independently to the above, SRFI 165 changes what the runtime
representation of a state variable can be. [...]
Paraphrasing: "Are they symbols or identifiers bound to state objects?"
In general, something that acts like a variable identifier should be
hygienic, and it was most likely a mistake for SRFI 159 to use symbols.
Having sorted out implementation details to my satisfaction, the only
argument I can think to prefer symbols is relative ease of loading
formatters from text files (e.g. gettext, one of the other outstanding issues
that went untouched in the original discussion). You can evaluate
an expression in a safe (srfi 159) sandbox and still be able to refer
to new parameters, e.g. the gettext args, without having to worry about
hygiene (you could even compile by hand if eval made you nervous).
By contrast, if the state vars are hygienic you need to eval in the right
combination of environments, which may or may not be safe.
It's a weak argument and doesn't convince me.
I'd be open to writing a new SRFI which is a modified SRFI 159
having hygienic state variables hygienic, assuming other members
of WG2 would be willing to revote and include this in place of SRFI 159.
--
Alex