Am Mi., 5. Aug. 2020 um 08:07 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

>> They could still flag that they are in debug mode through the feature
>> identifier "debug". This should be easy to implement in any system
>> that implements feature identifiers, so, in particular, in every R7RS
>> system.

> Not all of them provide a way for users to specify a feature, though.

True, but they may have some other way to set a debug mode. And they
can signal such a debug mode to the running program through the
feature identifier set.

>> It may even be a good thing to have a lot of SRFIs in the
>> pipeline so that they can evolve together. It only becomes a problem
>> for reviewers if too many SRFIs are in the finalization stage.

> It's to be hoped that people don't just look at a SRFI during last call.  One should look at a SRFI during its discussion period too.

Unfortunately, this is very often not the case. Moreover, the number
of reviewers is usually a very small circle.

>> SRFI 189 makes a mistake here; unfortunately, it can only be corrected by a PFN.
>
>
> An inconsistency is not necessarily a mistake.  Language design is not FOPL.

In my opinion, it is a mistake to build in an inconsistency when it
was known as an inconsistency and when the consistent alternative
doesn't cost anything more.

Consistent, regular APIs are certainly a bigger thing in language design.

>
>>
>> I see one more problem with the current process, at least until
>> R7RS-large will be finished. Consider SRFI 159/166, for example. It is
>> SRFI 159 that is in the current (tangerine) edition of R7RS-large
>> under the name "(scheme show)". Assuming that the much improved but
>> slightly incompatible SRFI 166 will be voted into a future edition of
>> R7RS-large, the bindings in "(scheme show)" won't be stable. And we
>> don't have library versioning as in R6RS.
>
>
> We will see what the WG thinks on that issue.
>
>>
>> That's only a minor point. The much bigger problem is that the API to
>> ipairs is thoroughly impoverished. For example, you put "range->list"
>> or "range-map->list" into SRFI 196, which is great. But there is no
>> "range->ilist" or "range-map->ilist", etc.
>
>
> IMO coupling through standard Scheme data structures is better than an arbitrary mesh of couplings.  In any case, SRFI 158 can do a lot towards anything-to-anything conversion.

That's a good point. But how much code do you expect to actually use
SRFI 116 whenever the lists are conceptionally immutable (which most
Scheme lists seem to be)?

>> But on second or third thought, the proposal doesn't seem
>> to be helpful at all.
>
>
> "Not ideal" does not amount to "useless".

The problem is that its existence now may block better proposals.

Marc