Jim,

thanks for chiming in!

Am Mi., 13. Feb. 2019 um 06:16 Uhr schrieb Jim Rees <xxxxxx@gmail.com>:
>
> I sort-of more-or-less have something more appealing w.r.t. compile-time/hygienic matching, but very non-portable:
>
> 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.

> 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?

What do you mean by "match hygienically"? Being free-identifier=? (and
being bound-identifier=?) are well-defined concepts. How does "match
hygienically" fit into it?

How do you handle the case of unbound identifiers a and b? When is
(eq? (identifier->eqobj #'a) (identifier->eqobj #'b))?

> 3) The original define-environment-monad form still works, but there is also (declare-fields <monad-name> <fieldspec> ...), where a field spec is either (fieldname) or (fieldname default).  This is how an extension module can declare more state variables (and not worry about symbolic collisions).

Is fieldspec to be read as an identifier and not as a raw symbol?

> 4) (fn (col) ...) does not bind 'col'.   col, and all declared state variables are initially defined as syntax-parameters.  (fn (col) ...) binds a temporary identifier and then parameterizes col to be identifier-syntax for the temporary.

I guess what you want is that something like (fn (col) (each col (fn
(col) ...))) works.

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)))))

> 5) (fn ((current-column col)) ...) does the simpler thing, just binds current-column

What about (fn ((col col)) ...)?

> 6) fn, with!, and with forms expand to a syntax-error if a state-variable name is not a declared state variable associated with the same monad that defined these syntax.  (This was ugly to implement, but it definitely helped with debugging).

> So, the key non-portables here are identifier->eqobj and identifier-syntax.  Also to call identifier->eqobj with an identifier as an argument from syntax-rules macro output, (syntax id) -- aka #' -- is needed.

identifier->syntax seems to be less a problem as it is well-understood
and easy to implement for any expander. (Although I'm not sure whether
your use case is a particularly good use case for identifier-syntax.)
identifier->eqobj seems to be much more problematic.

> No need to pick this one apart.  It's not production-grade for sure.  Just though it might be interesting, and I've love to hear what others are thinking on this topic.

While I always love to see ingenious solutions like the one you have
been sketching, I am wondering whether we really want to affix such
singular syntax and semantics to SRFI 159 (which could otherwise be
portably implemented), in particular as your proposed change would not
be backward compatible with SRFI 159 so would need an amended SRFI 159
anyway.

If we agree on that it was a suboptimal choice (apparently due to
historic reasons) that state variables are raw symbols, I don't see a
fundamental problem in changing SRFI 159 minimally and to replace SRFI
159 by the amended version in the next edition of R7RS-large (this has
already been done with SRFI 121/158).

-- Marc

>
>
> On Mon, Feb 11, 2019 at 7:48 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>>
>> Am Mo., 11. Feb. 2019 um 10:43 Uhr schrieb Alex Shinn <xxxxxx@gmail.com>:
>>
>> [...]
>>
>> > Without spending much time thinking about this originally I didn't consider it even possible in portable R7RS small, but I realize we could bind these to unique objects and key on those instead of the identifiers.
>> >
>> > If we really want this it would be a significant deviation, requiring changes to the spec and implementation, so would have to be a new SRFI.  I might take this up if there were serious interest from R7RS large.
>>
>> [...]
>>
>> I would volunteer to write a SRFI about the environment monad (which
>> may be of independent interest as well) and whose implementation can
>> then be used as a basis for SRFI 159 (thanks to the modular
>> implementation of SRFI 159 this is easy to achieve).
>>
>> How are `local′ and `local!′ (or `with′ and `with!′, respectively)
>> supposed to interact? There are four possibilities:
>>
>> (1) `local′ conceptually creates a new scope. All changes introduced
>> by `local!′ inside this scope are revoked when the `local′ scope is
>> left.
>> (2) Only changes by `local!′ to variables introduced by `local′ are
>> revoked when the `local′ scope is left.
>> (3) Changes by `local!′ always persist, even across `local′ scopes.
>> (4) It's up to the implementation.
>>
>> (chibi monad environment) currently implements (2).
>>
>> -- Marc
>> To unsubscribe from this list please go to http://archives.simplelists.com
>
> 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/