* bug#38672: Core records and R7RS records @ 2019-12-19 16:24 Marc Nieper-Wißkirchen 2019-12-19 17:47 ` John Cowan 2020-01-12 20:57 ` Andy Wingo 0 siblings, 2 replies; 4+ messages in thread From: Marc Nieper-Wißkirchen @ 2019-12-19 16:24 UTC (permalink / raw) To: 38672 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#38672: Core records and R7RS records 2019-12-19 16:24 bug#38672: Core records and R7RS records Marc Nieper-Wißkirchen @ 2019-12-19 17:47 ` John Cowan 2019-12-20 12:47 ` Marc Nieper-Wißkirchen 2020-01-12 20:57 ` Andy Wingo 1 sibling, 1 reply; 4+ messages in thread From: John Cowan @ 2019-12-19 17:47 UTC (permalink / raw) To: Marc Nieper-Wißkirchen; +Cc: 38672 [-- 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 --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#38672: Core records and R7RS records 2019-12-19 17:47 ` John Cowan @ 2019-12-20 12:47 ` Marc Nieper-Wißkirchen 0 siblings, 0 replies; 4+ messages in thread From: Marc Nieper-Wißkirchen @ 2019-12-20 12:47 UTC (permalink / raw) To: John Cowan; +Cc: 38672 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#38672: Core records and R7RS records 2019-12-19 16:24 bug#38672: Core records and R7RS records Marc Nieper-Wißkirchen 2019-12-19 17:47 ` John Cowan @ 2020-01-12 20:57 ` Andy Wingo 1 sibling, 0 replies; 4+ messages in thread From: Andy Wingo @ 2020-01-12 20:57 UTC (permalink / raw) To: Marc Nieper-Wißkirchen; +Cc: 38672-done 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-01-12 20:57 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-12-19 16:24 bug#38672: Core records and R7RS records Marc Nieper-Wißkirchen 2019-12-19 17:47 ` John Cowan 2019-12-20 12:47 ` Marc Nieper-Wißkirchen 2020-01-12 20:57 ` Andy Wingo
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).