bug-guile
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#38672: Core records and R7RS records


From: Marc Nieper-Wißkirchen
Subject: bug#38672: Core records and R7RS records
Date: Fri, 20 Dec 2019 13:47:47 +0100

Am Do., 19. Dez. 2019 um 18:48 Uhr schrieb John Cowan <address@hidden>:
>
> 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]