Am Di., 12. Mai 2020 um 05:06 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

>> "Because of the Liskov Substitution Principle, it is not possible to
>> treat [im]mutable pairs as either a subtype or a supertype of mutable
>> ones; they must be distinct, ..."

> I have added some passages to clarify that there are two kinds of implementations: Type A, where pairs from literals are pairs, and Type B where they are ipairs.  In a Type A implementation pairs and ipairs are disjoint, whereas in a Type B implementation ipars are a subtype of pairs.

Where did you add these passages?

But what does this mean with respect to the Liskov Substitution
Principle (with also appears regularly in the ongoing discussion about
(immutable) strings)? Formerly, the wording was that the Liskov
substitution principle forbids either type to be a subtype of the
other; now it seems that the immutable type may be a subtype of the
mutable one. There can only be one truth. And what would this imply
for (immutable) strings?

> The modified text no longer "recommends" but only "recognizes" that such an approach may be taken, and if so, pair procedures must work on iaprs as well.

From a user's perspective, the previously "recommended" approach seems
to be the simpler one. Otherwise, we have three types, namely "mutable
mutable pairs", "immutable mutable pairs" and "immutable pairs".

>> Related to this question: Would it be a faithful implementation if all
>> the procedures exported by SRFI 116 are the same as their mutable
>> counterparts without the "i"-prefix? In such an implementation, there
>> does not seem to be any meaningful difference between pairs and
>> ipairs.

> If an object is created by icons, it must still be the case that set-car! and set-cdr! fail on it.

As anything can happen in an error situation, this is not an
observable restriction.

(For most Schemes, which do not have an immutable pair type, the
trivial implementation of making no difference between mutable and
immutable pairs will, in fact, be the most efficient one.)