Re: The Liskov Substitution Principle in the Rationale
Marc Nieper-WiÃkirchen 16 May 2020 21:16 UTC
Am Sa., 16. Mai 2020 um 20:54 Uhr schrieb Marc Nieper-Wißkirchen
<xxxxxx@nieper-wisskirchen.de>:
[...]
> >> While a PFN may not be normative, some implementations will now
> >> provide the old semantics under the SRFI 116 name, other
> >> implementations will provide the new semantics. That worse than just
> >> one semantics.
> >
> >
> > Unfortunately, even before this PFN, that was already the case, again because the removed text was a recommendation, not a requirement, of the SRFI.
>
> Right, this only narrows implementations.
While this sounds innocent, it means that portable code cannot rely on
the narrower semantics of the PFN, casting doubt in another way on it.
While I, personally, don't think that the PFN goes in the right
direction, others may think differently but still wouldn't be able to
take advantage of it.
Marc
PS We have also talked about immutable strings. While we want to make
it an error to mutate these strings (so that, for example,
implementations that use UTF-8 internally can still maintain O(1)
character access) forcing them to be a distinct type (in the sense of
type predicates) adds an unnecessary burden on those implementations
that, say, use UTF-32 internally.
Semantically, there are two different types of strings (respectively,
pairs). But this semantic difference does not have to be reflected by
type predicates. It needn't be an observable property.