Re: either-guard reference implementation John Cowan (29 Jul 2020 23:18 UTC)
Re: either-guard reference implementation Marc Nieper-Wißkirchen (31 Jul 2020 08:36 UTC)
Re: either-guard reference implementation John Cowan (05 Aug 2020 06:07 UTC)
Re: either-guard reference implementation Marc Nieper-Wißkirchen (05 Aug 2020 06:22 UTC)
Re: either-guard reference implementation John Cowan (05 Aug 2020 06:28 UTC)
Re: either-guard reference implementation Marc Nieper-Wißkirchen (05 Aug 2020 06:48 UTC)
Re: either-guard reference implementation John Cowan (07 Aug 2020 22:08 UTC)
Re: either-guard reference implementation Marc Nieper-Wißkirchen (09 Aug 2020 11:14 UTC)
Re: either-guard reference implementation John Cowan (09 Aug 2020 13:10 UTC)
Re: either-guard reference implementation Marc Nieper-Wißkirchen (11 Aug 2020 08:14 UTC)
Re: either-guard reference implementation John Cowan (11 Aug 2020 16:48 UTC)
Re: either-guard reference implementation Marc Nieper-Wißkirchen (15 Aug 2020 12:11 UTC)
Re: either-guard reference implementation John Cowan (15 Aug 2020 13:57 UTC)

Re: either-guard reference implementation Marc Nieper-Wißkirchen 05 Aug 2020 06:22 UTC

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