Am Mo., 11. Feb. 2019 um 08:18 Uhr schrieb Alex Shinn <xxxxxx@gmail.com>:
>
> On Mon, Feb 11, 2019 at 12:38 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:

[...]

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

>
> 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. The set of formatters is fixed at runtime
(barring those generated through `eval'), so the state variables are
conceptually as well. Indeed, `with', `fn', ... are all macros and do
not evaluate the `state-var' "argument" so the set of state-var
symbols is bound by the number of instantiations of `with', `fn', ...

(If one really needs runtime-generated state variables, one could
define a single static one bound to an alist or hashmap.)

I still believe that my analogy with record types is correct. Records
can be inherited, formatters can be combined. Imagine two libraries
(show hearts) and (show foos), both of which are built upon (srfi
159). Both use a custom state variable named `size', say for the size
of the hearts to be displayed and for some display parameter for foos.
Formatters exported by the two libraries are not easily combinable as
changing the `size' state of the heart formatters automatically change
a completely unrelated state for the foo formatters.

It's even worse: The `size' state variable of `(show foos)' may be an
internal one used by the implementation. And as the names state-vars
are fixed, one cannot even use something like `gensym' to generate
private state-vars. So the situation is actually worse than in a LISP
with dynamic scoping and without hygienic macros.

A real-life example (instead of (show foos)) is actually Chibi's
(chibi show c), which defines custom state variables like
`expression?' or `op'. These should be an implementation detail.

Thanks,

Marc

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