On 27 June 2016 at 11:02, Marc Nieper-Wißkirchen
<xxxxxx@nieper-wisskirchen.de> wrote:
> 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. (snip ...).  In SRFI 136, the parent constructor's arguments
> are solely referred to by position, so the problem is bypassed.
It seems the same strategy as R6RS's 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 think it's better to say it in the SRFI. (there might be people, like me,
who don't read this SRFI's pupose like that)

> Yes. This makes introspection possible already at the syntactic level. For
> the procedural level, the predicate serves as the record-type identity.
I think it might be better to say it explicitly rather than implicitly.

> 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.
Ah, ok. The SRFI doesn't specify those procedures, so I thought it needs to
evaluate the expression described in the section.

>> - 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.
Does it mean the name argument must be a simple of already defined record type?
Then I don't see the purpose of this procedure. (Maybe there's miscommunication.
I meant a symbol of 'not yet defined record type name')

> 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)?
I looked sample implementation. (Sorry, I didn't when I wrote comments).
I thought it requires some sort of storage to lookup record type since predicate
is mere procedure (which is misunderstanding) and there's no way to retrieve
or store extra information from/to procedure.

> 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.
You might want to have a look at it. Or if you dislike R6RS, you can also see
withdrawn SRFI-76 (I believe this is the base of R6RS record), since its field
access is also done via index base.

Cheers,

--
_/_/
Takashi Kato
E-mail: ktakashi19@gmail.com