Am 27.06.2016 um 10:03 schrieb Takashi Kato:
> Hi,
>
> I have couple of comments for this SRFI:
Your comments are very much appreciated. I am going to incorporate the
essence in the next draft.

> - What's the significant difference amoung the other record related SRFIs,
>    especially SRFI-99? This is 6th record relared SRFI, so it would be nice
>    to have why this SRFI is needed. (To me, it seems almost identical to
>    SRFI-99 but just a bit of procedural difference)
The main difference to SRFI 99/SRFI 131 is that SRFI 99/SRFI 131 relies
on the identities of the parent's field names in a child's constructor.
This was the main reason why I wrote SRFI 136 as there is no consensus
in WG 2 so far what a field name in R7RS-small record types actually is
(a symbol, an identifier possibly renamed by macro expansion, ...). In
SRFI 136, the parent constructor's arguments are solely referred to by
position, so the problem is bypassed.

> - The SRFI says, it's extension of R7RS small's record type. Does this mean
>    a record type which is defined with define-record-type in (scheme base)
>    can be extended by this SRFI's define-record-type?
The intended meaning of "it's an extension of R7RS-small's record type"
is that any implementation of SRFI 136 could be included in (scheme
base). I don't see a way how a record type defined by the original
define-record-type in (scheme base) in an unsupporting implementation
can by syntax of this SRFI because the record-type descriptor of
R7RS-small can be anything and may not even carry any information, so
introspection is not possible.

> - <parent> on Syntax section is specified to be a <keyword>. Shouldn't it be
>    <type name>? And also specify <type name> will be bound to macro keyword
>    instead of implicitly saying it on Rationale? (though, <macro use> requires
>    <type name> to be a macro so maybe not)
Yes, it seems better to specify that <parent> is <type name> and to say
explicitly that <type name> will be bound to a keyword.

> - Above implicit indication and the description of <type name>, I can read
>    record-type descriptor is a macro, is it intentional?
Yes. This makes introspection possible already at the syntactic level.
For the procedural level, the predicate serves as the record-type identity.

If we want the record-type descriptor to be a variable instead of a
keyword, syntactic introspection would only be possible if we tweaked
define-record-type as in, say:

(define-record-type (<child-procedural-rtd> <parent-syntactic-rtd>
<child-syntactic-rtd>)
   ...)

for subtyping while retaining syntactic introspection and

(define-record-type (<child-procedural-rtd> <parent-procedural-rtd>)
   ...)

for doing subtyping only at the procedural level.

Currently, the implementation relies heavily on the syntactic introspection.
> - In description of <macro use>, if a record-type description doesn't have
>    parent, then the expanded form would have #f as <parent> or it'd be ommited?
In the sample implementation, it has #f. Omitting wouldn't work because
distinguishing the parent from the first field-spec would be impossible.
This should be added to the description, though.

> - I think make-record-type-predicate is ugly since it requires eval. Why
>    don't you use implicitly defined type record-type descriptor? (Of course,
>    if it's not a macro though)
Why do you think it requires eval? (I would agree that it was ugly if it
required it.) The sample implementation does not use eval. The rationale
behind make-record-type-predicate is that going from the syntactic to
the procedural layer is one-way. As soon as you create a subtype via
make-record-type-predicate, you can only use it with the procedural layer.

But maybe I am missing your point.

> - What would happen if make-record-type-predicate gets not yet defined record
>    type as its first argument?
It is an error because the procedure is called with unsupported arguments.

> - How does the field-vector, argument of make-record, look like? Is this a
>    vector of field values or the element contains filed name as well?
Just a vector of field values in the order of the field specs beginning
with the field specs of the oldest ancestors. Should probably be
clarified in the spec.

> This might be a bit off topic. The SRFI seems to require a storage which is
> used to lookup record-type descriptor by either <type-name> or predicate. I
> think it's ugly since it also means single namespace (or library) to manage
> these information. (Maybe there's a better way not to do like that).
Sorry, I am a bit slow-witted here and didn't get your point. Could you
explain it again (maybe with references to the sample implementation in
case you have taken a look at it)?

> And this might be releated to the first bullet of the comments, why not using
> R6RS record without implicit field accessor or facility reduced?
I am no expert on R6RS. SRFI 99/SRFI 131 seems to have been written to
remove inadequacies of R6RS. My own proposal is based directly on the
ideas I got from reading SRFI 9/99/131.

Best,

Marc