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:48 UTC

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