Am Di., 23. Apr. 2019 um 17:51 Uhr schrieb Alex Shinn <xxxxxx@gmail.com>:
>
> On Tue, Apr 23, 2019 at 11:20 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>>
>> Am Di., 23. Apr. 2019 um 17:02 Uhr schrieb Alex Shinn <xxxxxx@gmail.com>:
>> >
>> > I apologize for the very long delay.
>> >
>> > On Fri, Apr 5, 2019 at 10:00 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>> >>
>> >> (1) For the sake of applicability and coherence, SRFI 166 should be
>> >> compatible with SRFI 165. Problems that may be an obstacle to that
>> >> should (and can) be addressed in either SRFI 165 or SRFI 166 before
>> >> both are finalized.
>> >>
>> >> When a future SRFI standardizes the notion of monads, SRFI 165 should
>> >> and would become an implementation of that notion, so SRFI 166 would
>> >> automatically gain from it.
>> >
>> >
>> > I'm sorry but I still fail to see any practical example where an explicit dependence on SRFI 165 is an advantage.
>> >
>> > On the other hand, although you've made an extension for predefined environment variables in SRFI 165, it doesn't allow for low-level optimizations as currently implemented, where predefined variables get a fixed memory offset in a state record.  SRFI 166 is potentially extremely lightweight, and all around faster than format-string-based libraries, but this is diminished when composition requires a lot of overhead in state updates.
>>
>> Indeed, it does allow for the low-level optimization you are asking
>> for. In the current implementation of SRFI 165, predefined variables
>> correspond to a fixed memory offset in what you call the state record.
>> Accessing and updating them is already very lightweight in the current
>> implementation and practically as optimized as in SRFI 159's original
>> implementation.
>
>
> On re-reading, I must have missed the following caveat:
>
>> Each ⟨variable⟩ is bound to an environment variable, which can only be used with an environment created by invoking the procedure bound to ⟨make-environment⟩
>
>
> Thus these predefined vars cannot be used with other environments,
> just as opaque formatters could not be.
>
> What do we gain?

Everything. :) The only thing we don't get is that *user*-predefined
variables cannot be used with the SRFI 166 formatters. (But the same
holds for the current implementation where the set of predefined
environment variables is fixed.)

In particular, all procedures that combine monadic procedures and
values in SRFI 165 do not care about how the environment has been
created. The caveat only applies to the predefined environment
variables.

Marc

>
> --
> Alex
>

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