This was listed as one of the issues in the early drafts, but there was no discussion around it. The SRFI defines 14 state variables, not a couple.
I think the primary rationale for using symbols was that I wanted short names for the common variables, which would be too likely to conflict with variables in user code.
Hi,I'm sorry that the following didn't occur to me before SRFI 159 was finalized and voted into the Tangerine Edition, but maybe it can later be amended depending on how the following will be resolved.SRFI 159 defines a couple of state variables like `port' or `radix', which are represented by symbols. Using `with' and `with!', user code can define and bind custom state variables. However, this does not compose well because there is no namespacing and no lexical scope as state variables are raw symbols and not identifiers.Many, including the author of SRFI 159, have argued that the field names in R7RS records shall be represented by identifiers and not by symbols. All arguments in favor of that are also arguments in favor of SRFI 159's state variables being represented by identifiers.In case, state variables are identifiers, SRFI 159 would also have to export identifiers bound to the standard state variables `port', `row', etc.I haven't yet thought about how to implement this (one may have to introduce new state variables explicitly as it is done with SRFI 39 parameters), but independently, I think this would be a reasonable improvement to the current semantics of SRFI 159.Best,MarcTo unsubscribe from this list please go to http://www.simplelists.com/confirm.php?u=tir5wl7QvYvd2mk7Rcp5T7JI30gRtsVK