Re: Comments William D Clinger (29 Jun 2016 14:40 UTC)
|
Re: Comments
Marc Nieper-Wißkirchen
(29 Jun 2016 15:59 UTC)
|
Re: Comments
William D Clinger
(29 Jun 2016 18:22 UTC)
|
Re: Comments
Marc Nieper-Wißkirchen
(30 Jun 2016 11:56 UTC)
|
Re: Comments
William D Clinger
(01 Jul 2016 16:07 UTC)
|
Re: Comments
John Cowan
(29 Jun 2016 19:25 UTC)
|
Re: Comments
Marc Nieper-Wißkirchen
(30 Jun 2016 14:45 UTC)
|
Re: Comments William D Clinger 29 Jun 2016 14:40 UTC
"Instances belong to a type that is disjoint from any existing Scheme type, including types created by other calls to make-type." Does that mean the sample implementation would be illegal in implementations where records created by define-record-type are recognized by the record? predicate of (rnrs records) or (srfi 99) as belonging to the type consisting of all records? Scheme has no official notion of type, so "a type that is disjoint from any existing Scheme type" is meaningless without further explication. The sentence quoted above should be replaced by something along the lines of the following sentence of SRFI 9: "Records are disjoint from the types listed in Section 4.2 of R5RS." As has been mentioned by others already, this SRFI's notion of subtyping affects only the predicates returned by the make-type and make-subtype procedures, and bears no relationship to the Liskov substitution principle. Marc Nieper-Wißkirchen wrote: > While they provide unique types, neither SRFI-9 nor R7RS-small > records provide subtypes. SRFI 137 doesn't provide subtypes either. It just uses the word "subtype" in a misleading way. > More sophisticated record systems like SRFI 131 or SRFI 136 > provide subtypes. When the underlying implementations differ, > however, it may not be possible to intertwine, say, SRFI 131, > SRFI 136, and (rnrs records) in inheritance chains of subtypes. The reason it is not possible to create chains of record subtypes that include record types defined by both SRFI 131 and SRFI 136 is simple: SRFI 131 matches field names by name as though they were symbols, while SRFI 136 uses positional matching. That incompatibility cannot be removed by cleverness of implementation, and that incompatibility is not ameliorated by SRFI 137. Adding yet another incompatible notion of subtypes does not improve the situation. We have prior art in which inheritance chains of record subtypes can mix record types defined using (srfi 9), (rnrs records), (srfi 99), (srfi 131), and (scheme base). The only problem with that is a recent claim that records defined by (scheme base) are not intended to be compatible with record systems in which field names are symbols. Implementations can ameliorate that problem (without resolving it for portable code) by ignoring that recent claim. WG2 has the power to resolve that situation or to make it worse. We'll see. > If all implementations of record-type systems agree on using > SRFI 137 for creating and subtyping types, they will at least > be compatible in this regard. That is not going to happen. I suppose WG2 could mandate that for R7RS (large), but it would be hard to sell that mandate during the ratification process. Even if ratified, the primary effect of that mandate would be to discourage implementations from implementing R7RS (large). SRFI 137 adds another dimension of inheritance incompatibility. Implementations can resolve that new problem by simply ignoring SRFI 137, or by implementing SRFI 137 without making even the slightest effort to create any interoperability between the useful notion of subtyping provided by (rnrs records), (srfi 99), and (srfi 131) and the cockeyed notion of subtyping introduced by SRFI 137. Will