On Tue, Jul 25, 2017 at 2:39 AM, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:

I think it is problematic nevertheless: the fact that we need to revise old SRFIs to make them work shows that there is a problem with compositionality of the solution.

I think this is not a problem of the SRFIs. Any SRFI may build upon another one. E.g., by saying: "This SRFI extends SRFI 26 as follows ...".

It may be a problem of the implementation, though, because you cannot simply import the macros of SRFI 26 and add a few features programmatically. You'll have to rewrite the macro. But a future SRFI may contain a solution to make such a composition of macros directly possible.

Ease of implementation is certainly a factor to consider, but in this case I don't think it much an issue in practice. A Scheme implementation that chose to support srfi-26 plus this extension can just substitute its code to the enhanced version and no need to worry that the enhancement isn't piggybacked to the existing srfi-26 code. (Except that the Scheme implementation wants to offer strict error checking, so that 'cut' imported from (srfi 26) would raise an error on (cut is ...).)

I often implement srfis directly from the specification text, independent from their reference implementation, to make it work well with Gauche. The specification matters.