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.

[...]

Marc