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

> As I mentioned before, I expect immutable pairs and strings to be particularly useful in multithreaded code, so that users do not have to bother copying them in order to be thread-safe.

That looks like a misconception to me.

For that, we don't need immutable pairs or immutable strings. We need
algorithms that don't mutate the data structures, like those in SRFI
146, which are build on top of ordinary pairs and vectors.

Marc

>
> On Wed, Aug 5, 2020 at 2:22 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>>
>> 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