I don't think the intention of this srfi is to mandate specific internal

type system of implementations; I read it as a layer on top of which

portable libraries of various record/object systems are written, but

each implementation can still have native efficient support of record

types. (At least that's what I'd do in Gauche if I support this srfi; the

types created by this srfi is just another classes in Gauche's object

system, distinct from natively supported srfi-99 record types.)

But I'd imagine that many existing implementations would do the

same, and the "portable" record system on top of this srfi may

not be as efficient as natively supportd record types (for example,

an implementation's native record types may use single structure

for RTTI and payload; if so, supporting constructor and accessor

incurs overhead of copying the payload), and they

won't be interoperable with natively supported one (in a sense that

there's no guarantee that you can make-subtype on implementation-

supported srfi-9 records, for example.)

I'm afraid that it makes such portable implementations less attractive

than the ones that chooses to be built on top of one of the existing

record systems.

On Tue, Jun 28, 2016 at 11:00 PM, Takashi Kato <ktakashi19@gmail.com> wrote:

> 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

To unsubscribe from this list please goto http://www.simplelists.com/confirm.php?u=3TVbfc4P3IMjyMtZWN2TcTrisTp8UkgH