either-guard reference implementation Shiro Kawai 16 Jul 2020 02:14 UTC
Re: either-guard reference implementation John Cowan 16 Jul 2020 04:28 UTC
Re: either-guard reference implementation Wolfgang Corcoran-Mathe 16 Jul 2020 04:41 UTC
Re: either-guard reference implementation Wolfgang Corcoran-Mathe 16 Jul 2020 05:01 UTC
Re: either-guard reference implementation John Cowan 16 Jul 2020 15:11 UTC
Re: either-guard reference implementation Wolfgang Corcoran-Mathe 16 Jul 2020 17:24 UTC
Re: either-guard reference implementation John Cowan 16 Jul 2020 17:45 UTC
Re: either-guard reference implementation Wolfgang Corcoran-Mathe 16 Jul 2020 18:04 UTC
Re: either-guard reference implementation John Cowan 16 Jul 2020 18:06 UTC
Re: either-guard reference implementation Wolfgang Corcoran-Mathe 16 Jul 2020 18:28 UTC
Re: either-guard reference implementation John Cowan 16 Jul 2020 23:30 UTC
Re: either-guard reference implementation Wolfgang Corcoran-Mathe 17 Jul 2020 00:10 UTC
Re: either-guard reference implementation Arthur A. Gleckler 17 Jul 2020 03:14 UTC
Re: either-guard reference implementation Wolfgang Corcoran-Mathe 17 Jul 2020 04:27 UTC
Re: either-guard reference implementation Arthur A. Gleckler 17 Jul 2020 04:59 UTC
Re: either-guard reference implementation Wolfgang Corcoran-Mathe 17 Jul 2020 05:55 UTC
Re: either-guard reference implementation Marc Nieper-Wißkirchen 17 Jul 2020 05:55 UTC
Re: either-guard reference implementation Shiro Kawai 17 Jul 2020 07:35 UTC
Re: either-guard reference implementation Wolfgang Corcoran-Mathe 17 Jul 2020 13:40 UTC
Re: either-guard reference implementation Marc Nieper-Wißkirchen 17 Jul 2020 13:50 UTC
Re: either-guard reference implementation Arthur A. Gleckler 18 Jul 2020 05:22 UTC
Re: either-guard reference implementation Marc Nieper-Wißkirchen 18 Jul 2020 12:31 UTC
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:35 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:13 UTC
Re: either-guard reference implementation John Cowan 09 Aug 2020 13:09 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 16 Jul 2020 20:39 UTC
Re: either-guard reference implementation Wolfgang Corcoran-Mathe 16 Jul 2020 23:25 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