Am Mo., 11. Feb. 2019 um 09:10 Uhr schrieb Marc Nieper-Wißkirchen
<xxxxxx@nieper-wisskirchen.de>:

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

An idea just rushed into my mind how this problem can be resolved
while staying backward compatible with the current SRFI 159. At the
moment, a STATE-VAR in SRFI 159 is a <symbol> in the formal syntax of
the R7RS. In the reference implementation of SRFI 159, such a
STATE-VAR either ends up in a datum of the form (quote STATE-VAR) or
as a key in a `case' clause (which eventually expands to (quote
STATE-VAR) as well).

What about allowing STATE-VAR to be a <qq template 1> such that
(quasiquote STATE-VAR) evaluates to a datum? In that case, all the
problems raised above can at least be solved. In `(show hearts)', we
could write (define %size (gensym)) and (define (size) %size) so that
`size' is being exported. Code using `(show hearts)' would then use
`(with ((,(size) 10)) ...)' instead of `(with ((size 10)) ...)'.

Likewise, (chibi show c) would not have to leak implementation details.

The changes to the implementation would be trivial. Some quote's have
to be replaced by some quasiquote's and the `case' constructs have to
become cond's.

Cheers,

Marc

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

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