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 09 Aug 2020 11:13 UTC

Am Sa., 8. Aug. 2020 um 00:08 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

> On Wed, Aug 5, 2020 at 2:48 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>
>> > 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.
>
>
> Most Lispers don't program in the large, so they don't have to deal with code written by someone else that may be of lesser quality.  Passing around immutable data structures means that however buggy the other code may be, it can't corrupt your data.  And that's just one consideration.

- This has nothing to do with multithreaded code, about which your
first argument was, does it?

- I find it hard to conceive a realistic scenario of what you
describe. If the other code is buggy and cannot be trusted, what do I
gain by passing any data structure to it?

- But in a case, in which we assume such a scenario, we actually want
immutable data that does not form a new Scheme type (see my latest
contributions to the SRFI 116 mailing list) and not immutable data
that forms a disjoint type because such third-party code in question
will usually not be written using ipairs and texts but pairs and
strings.

- There are conceptually immutable data structures (for which I can
use, say, ordinary pairs), but there aren't de facto immutable data
structures in view of the existence of record inspection and other
implementation-dependent low-level procedures (so there no total
safety against buggy code). I guess that even in Haskell, one can use
unsafe constructs to modify thunks in place.

- For the example with the buggy code, R6RS's attempt to move
"set-car!" and "set-cdr!" into an extra library doesn't look too bad
if there is a way to prevent such buggy code to import this extra
library.

PS I hope we can have some larger discussion about the best concept of
immutability in R7RS-large at some point. Hopefully, this will also
resolve the not-yet solved problem about strings. For the time being,
I think that the best backward-compatible solution is that we have
mutable and immutable strings (whose immutability is nothing that the
implementation is enforced to enforce) but that both are not
necessarily distinguishable through type predicates at runtime. (Later
we may add expansion-time facilities to do that.) String literals will
belong to the latter category. The R7RS-small procedures creating
strings will create strings of the former category. A perspective
immutable string API will be able to create strings of the latter
category (which guarantee O(1) random access). Mutable strings would
silently be convertible to immutable ones. The same would apply for
pairs and immutable pairs.