Comments
Takashi Kato
(28 Jun 2016 19:40 UTC)
|
Re: Comments
Marc Nieper-Wißkirchen
(29 Jun 2016 07:21 UTC)
|
Re: Comments Takashi Kato (29 Jun 2016 09:00 UTC)
|
Re: Comments
Shiro Kawai
(29 Jun 2016 09:39 UTC)
|
Re: Comments
Marc Nieper-Wißkirchen
(29 Jun 2016 15:04 UTC)
|
Re: Comments
John Cowan
(29 Jun 2016 20:20 UTC)
|
Re: Comments
John Cowan
(29 Jun 2016 20:16 UTC)
|
Re: Comments Takashi Kato 29 Jun 2016 09:00 UTC
> Maybe one should say that this SRFI is a minimal extension to R7RS-small > that provides *unique* and *subtypeable* types. So does this mean the SRFI meant to be a part of R7RS-large? > While they provide unique types, neither SRFI-9 nor R7RS-small records > provide subtypes. Like I said, you can implement more sophisticated record systems on top of them. > 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. > 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. IMO, this SRFI takes away some freedom from implementations (not record type). For example, Sagittarius, which supports both R6RS and R7RS, uses own object system to implement both R6RS and R7RS-small (the same as SRFI-9) record systems. But if this SRFI (well, hoping not but) mandates to be underlying type system of all record systems and (again hoping not) will be a part of R7RS-large, then implementations can not choose to use own object system for R7RS. Moreover, this SRFI looks rather adhoc to me, because: 1. It can not be a base of whole Scheme types (correct me if I'm wrong) 2. There's no way to retrieve parent payload value by parent accessor. To me, this is rather weird/broken type system. (again correct me if I'm missing something) 3. It seems this SRFI is created because SRFI-136 can't be implemented without keeping compatibility of other record types. Cheers, -- _/_/ Takashi Kato E-mail: ktakashi19@gmail.com