Email list hosting service & mailing list manager

Weaken disjointness of range type? Marc Nieper-Wißkirchen (01 Sep 2020 11:25 UTC)
Re: Weaken disjointness of range type? John Cowan (01 Sep 2020 18:19 UTC)
Re: Weaken disjointness of range type? Marc Nieper-Wißkirchen (01 Sep 2020 19:45 UTC)
Re: Weaken disjointness of range type? Wolfgang Corcoran-Mathe (04 Sep 2020 23:15 UTC)
Re: Weaken disjointness of range type? John Cowan (05 Sep 2020 03:03 UTC)
Re: Weaken disjointness of range type? Marc Nieper-Wißkirchen (05 Sep 2020 10:15 UTC)
Re: Weaken disjointness of range type? Wolfgang Corcoran-Mathe (05 Sep 2020 19:27 UTC)
Re: Weaken disjointness of range type? Marc Nieper-Wißkirchen (06 Sep 2020 07:25 UTC)
Re: Weaken disjointness of range type? John Cowan (05 Sep 2020 23:35 UTC)
Re: Weaken disjointness of range type? Marc Nieper-Wißkirchen (06 Sep 2020 07:36 UTC)
Re: Weaken disjointness of range type? John Cowan (07 Sep 2020 01:09 UTC)
Re: Weaken disjointness of range type? Marc Nieper-Wißkirchen (07 Sep 2020 06:18 UTC)
Re: Weaken disjointness of range type? John Cowan (08 Sep 2020 15:40 UTC)
Re: Weaken disjointness of range type? Marc Nieper-Wißkirchen (08 Sep 2020 15:58 UTC)
Re: Weaken disjointness of range type? Marc Nieper-Wißkirchen (05 Sep 2020 09:49 UTC)

Re: Weaken disjointness of range type? Marc Nieper-Wißkirchen 06 Sep 2020 07:35 UTC

Am So., 6. Sept. 2020 um 01:35 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

>> Particular implementations can give you the guarantee, or a future SRFI. At the moment, nothing would change but enabling potential future guarantees.

> What ranges (as currently specified) do provide is a guarantee of immutability by construction: there is no way to even attempt to mutate them.  Literal vectors provide no such negative guarantee.  You can attempt to mutate them: the action may succeed (as is the case in about half of all current Schemes), may raise an exception, or may make demons fly out of your nose.  The distinction between it-is-an-error immutability and by-construction immutability is something I wish to preserve.

Agreed; this should not be weakened for ranges. The question is, how
to formulate this in technical terms. Just by saying, it is an error
to mutate a range does not help. So what about adding the following:

"Ranges do not denote locations. So, in particular, as much as it is
impossible to mutate a Scheme number, it is impossible to mutate a
range. For more about locations and mutability, see section 3.4 of the
R7RS on the Scheme storage model."

(Such wording makes sense with or without the addition that would
allow an implementation not to expose the difference between a vector
and a range to the user.)