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 11 Aug 2020 08:14 UTC

Am So., 9. Aug. 2020 um 15:10 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

>> third-party code in question
>> will usually not be written using ipairs and texts but pairs and
>> strings.
>
>
> That is true, and it would certainly be more convenient if procedures accepting pairs also accept ipairs as well. However, I believe that putting such a requirement on implementers of SRFI 116 (which would make it unportable) will hinder and not help adoption.  SRFI 116 leads the horse to water but cannot compel him to drink.

Standard pair procedures already accept immutable pairs in the form of
datum literals. Just drop "ipair?" from SRFI 116 and the route to
adoption is easy. And some implementations will actually drink the
water offered and make some pairs truly immutable (as many
implementations already do for pair literals).

>> - 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).
>
>
> There is no such thing as "total safety".  There may be low-level procedures that permit altering the bits of bignums, but we don't normally defend against this by making copies of them before passing them to unknown code; indeed, I know of no language with a "number-copy" procedure.
>
> In any case, R6RS signals an error if any attempt is made to retrieve the mutator of an immutable field.  SRFI 99 is less definite about it, but I believe it is implied by the use of "immutable" there.

My point wasn't so much about the practicability or the probability of
mutation of data structures declared as immutable in one way or the
other; I wanted to stress the fact that we have been confusing two
meanings of immutability all the time, which, in particular, led to
the IMHO suboptimal SRFI 116:

(1) Conceptual Immutability.
(2) Actual immutability.

>> 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)
>
>
> Then it is useless from the risk-mitigation viewpoint.

Not at all, I think. Implementations will, of course, be encouraged to
detect the mutation of an immutable string as much as they are
encouraged to detect when, say, "car" is applied to a number.

From a risk-mitigation viewpoint, you won't choose an implementation
that is silent on "(car 0)" either. We can expect that most quality
implementations will detect the error once they have found time to
adopt immutable strings, vectors and pairs. The good thing with this
approach is that all existing code will still work. And code that
claims to not mutate an input data structure can be fed such immutable
data (or a good implementation will complain).