Hi Alex, hi John,

if you don't mind, could we debate in WG2 the question that been
raised in this thread
https://srfi-email.schemers.org/srfi-159/msg/10433589?

The question is whether there is an incentive to modify SRFI 159 (aka
(scheme show)) so that — sloppily expressed — its state variables
become hygienic (so that SRFI's 159 promise in the abstract "... for
easily concatenating, composing and extending these formatters ..."
becomes true without exceptions).

(I would like to see a resolution before SRFI 165 is about to be
finalized as SRFI 165 shall be compatible either with SRFI 159 as
currently written or its amended version).

Thanks,

Marc

Am Mo., 11. Feb. 2019 um 10:43 Uhr schrieb Alex Shinn <xxxxxx@gmail.com>:
>
> On Mon, Feb 11, 2019 at 4:10 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>>
>> Am Mo., 11. Feb. 2019 um 08:18 Uhr schrieb Alex Shinn <xxxxxx@gmail.com>:
>> >
>> >
>> > It's worse than that though, since the identifiers conflict with themselves - you're likely to want nested formatters referring to the `col` variable (the ref impl does this), for instance, and this would no longer be possible without renaming.
>>
>> Maybe I don't understand the problem, but isn't the simple solution to
>> write, say, `(fn ((%col col)) ...)' instead of `(fn ((col col)) ...)'
>> or `(fn (col) ...)' in these cases?
>
>
> Yep, that's what I meant by "renaming."  I'm not sure how often this will bite people.
>
>>
>> > Conceptually, these variables are a runtime mapping (alist but could be hashmap), not a fixed record, so the analogy you propose isn't valid.  Not only is it strange to generate identifiers at runtime, it's not possible in portable R7RS small.  For example, if you want to load `show` templates dynamically from a text source (e.g. from gettext translations) then you really want to work with symbols, not identifiers.
>> >
>>
>> I don't understand the use-case in which one has to generate new
>> variables at runtime.
>
>
> I could imagine some, however I realize that as part of the cleanup from the original `fmt` design, I removed the ability to dynamically reference variables - all state variables must be statically written in a `fn` or `with`.
>
> Another concern I had was the inability to implement runtime matching on identifiers portably.  Unlike with record inheritance, the combinators support "injection" of new variables from separate sources.  Thus there is no way to register these as fixed fields like in a record - the underlying implementation must use an alist or other mapping.
>
> 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.
>
> --
> Alex
>
> 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/