bug#38672: Core records and R7RS records

bug#38672: Core records and R7RS records

[Marc Nieper-Wißkirchen]

I've read in the news that the upcoming Guile 3.0 will unify records.

Core records type seem to support the procedure "record-accessor",
which takes a field name as a symbol.

In R7RS (based on SRFI 9), record field names are, however, (hygienic)
identifiers and thus compile-time and not run-time identities. An R7RS
record type can, therefore, not support "record-accessor" and similar
procedures.

How is this going to be solved in Guile 3?

See the Rationale of SRFI 150 why R7RS record types use hygienic
identifiers (and should do so) for field names.

Marc

bug#38672: Core records and R7RS records

[John Cowan]

[-- Attachment #1: Type: text/plain, Size: 1353 bytes --]

While I esteem Marc's work highly, I have to say that his message above is
incomplete and tendentious.  He links to SRFI 150, written by him, in which
he links to a message by Alex Shinn (R7RS-small editor and Chibi
implementer) in support of this view.  This is a single message in the
thread <
https://groups.google.com/forum/#!topic/scheme-reports-wg2/oKuhgwaM45w>.
Reading the thread makes it clear that Alex and Marc are on the hygienic
side, Will Clinger on the non-hygienic side, and there is no agreement
about what the R7RS-small voters and editors intended, and indeed a
reasonable suspicion that they were talking past one another.

I have no axe to grind here.  I am a fairly heavy user of R7RS-small
records, but I use them only in SRFI 9 compatible ways: that is, in the
global scope and without attempting to generate them using macros.  So I
don't care personally how the answer comes out.

The difference really starts to bite when you add inheritance, however.  I
consider the two positions unlikely to be reconciled, and I think
inheritance of records is fairly unimportant as a feature (google for
"inheritance considered harmful" for arguments), so I have not placed the
question on the R7RS-large agenda at <
https://bitbucket.org/cowan/r7rs-wg1-infra/src/default/ColorDockets.md>,
though if enough people request it I will do so.

[-- Attachment #2: Type: text/html, Size: 1695 bytes --]

bug#38672: Core records and R7RS records

[Marc Nieper-Wißkirchen]

Am Do., 19. Dez. 2019 um 18:48 Uhr schrieb John Cowan <cowan@ccil.org>:
>
> While I esteem Marc's work highly, I have to say that his message above is incomplete and tendentious.  He links to SRFI 150, written by him, in which he links to a message by Alex Shinn (R7RS-small editor and Chibi implementer) in support of this view.  This is a single message in the thread <https://groups.google.com/forum/#!topic/scheme-reports-wg2/oKuhgwaM45w>.  Reading the thread makes it clear that Alex and Marc are on the hygienic side, Will Clinger on the non-hygienic side, and there is no agreement about what the R7RS-small voters and editors intended, and indeed a reasonable suspicion that they were talking past one another.

I should add that I didn't link SRFI 150 to support my claim through
my own claims :). I just didn't want to repeat the arguments there.
WG1 was aware of the two possibilities to implement
`define-record-type':
https://groups.google.com/forum/#!msg/scheme-reports-wg1/lk1ssmvgELs/n1j24HqNp2wJ.
Aaron W. Hsu gave some arguments on why hygiene should be maintained
and no one objected about his main point. In the end, the R7RS editors
used the terminology "identifier" when talking about record field
names in the final report, and not "symbols". (Quoting John from the
linked thread: "In SRFI-99 the field names are symbols, not
identifiers, so they are exposed as part of the type.")

>
> I have no axe to grind here.  I am a fairly heavy user of R7RS-small records, but I use them only in SRFI 9 compatible ways: that is, in the global scope and without attempting to generate them using macros.  So I don't care personally how the answer comes out.
>
> The difference really starts to bite when you add inheritance, however.  I consider the two positions unlikely to be reconciled, and I think inheritance of records is fairly unimportant as a feature (google for "inheritance considered harmful" for arguments), so I have not placed the question on the R7RS-large agenda at <https://bitbucket.org/cowan/r7rs-wg1-infra/src/default/ColorDockets.md>, though if enough people request it I will do so.

The problem shows up with inheritance but is not restricted to
inheritance. See the example of "define-record-type/identity" in SRFI
150. Without low-level macro systems and without gensyms (which R7RS
doesn't have) it wouldn't work with field names as symbols.

Howsoever this is going to be resolved, I still want to suggest that a
unification the various record systems in Guile should also allow an
implementation of SRFI 9/R7RS records where the field names are
identifiers and not symbols. Such fields would be invisible for
procedures like "record-accessor". To unify both worlds, core records
will, therefore, have to include a set of fields corresponding to
identifiers at compile-time (becoming numerical indices at run-time)
and another set of fields corresponding to field names given by
symbols. The procedural interface would only be able to create the
second type of fields.

Marc

bug#38672: Core records and R7RS records

[Andy Wingo]

On Thu 19 Dec 2019 17:24, Marc Nieper-Wißkirchen <marc@nieper-wisskirchen.de> writes:

> I've read in the news that the upcoming Guile 3.0 will unify records.
>
> Core records type seem to support the procedure "record-accessor",
> which takes a field name as a symbol.
>
> In R7RS (based on SRFI 9), record field names are, however, (hygienic)
> identifiers and thus compile-time and not run-time identities. An R7RS
> record type can, therefore, not support "record-accessor" and similar
> procedures.
>
> How is this going to be solved in Guile 3?

See
https://git.savannah.gnu.org/cgit/guile.git/commit/?id=86a9f9a27176968bbae46aceed114634ca7c693e
(just landed).

Cheers,

Andy