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