Am So., 10. Feb. 2019 um 16:48 Uhr schrieb Alex Shinn <xxxxxx@gmail.com>:
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.

It's my fault that I didn't pay attention to the early drafts. In fact, there was almost no discussion on earlier drafts so I guess that the issue was mostly ignored.
 
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.

I don't think that that would be much of a problem as imports from R7RS libraries can be renamed or prefixed. In fact, SRFI 159 already exports a number of short identifiers that could equally likely conflict with variables in user code (like `with' or `each' or `nothing'). Again, it is easy to prefix these in case it's needed.

Of course, the 14 predefined state variables could be handled special (this wouldn't be possible with `syntax-rules' alone) but that would look rather ugly in my opinion.
 
-- Marc

On Sun, Feb 10, 2019 at 11:32 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
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,

Marc

To unsubscribe from this list please go to http://www.simplelists.com/confirm.php?u=tir5wl7QvYvd2mk7Rcp5T7JI30gRtsVK



--
Prof. Dr. Marc Nieper-Wißkirchen
 
Universität Augsburg
Institut für Mathematik
Universitätsstraße 14
86159 Augsburg
 
Tel: 0821/598-2146
Fax: 0821/598-2090
 
E-Mail: xxxxxx@math.uni-augsburg.de
Web: www.math.uni-augsburg.de/alg/mitarbeiter/mnieper/