On Sun, Feb 9, 2025 at 2:33 AM Daphne Preston-Kendal <d...@nonceword.org> wrote:
> Indeed. If you hadn’t heard, I’m working with them on a capability-based > sublanguage for untrusted Scheme code (which is why this kind of thinking > is turning up more often in my Scheme writing lately, e.g. in SRFI 259 as > well). > Cool. Where can I read more? > Note this is the way R6RS record field names work (well, there they’re > accessible, as symbols, through the inspection layer, but this is merely > for informative purposes). There’s no requirement for them to be unique in > any sense, either, only if they’re not unique you can’t take advantage of > the automatic generation of accessor and/or mutator names. > I had forgotten that. > The problems of requiring ‘uniqueness’ and ‘correspondence’ in the > internal field names has led to the completely unnecessary and confused > debate about the sense in which field names have to be distinct or the > same, as explained in the rationale to SRFI 256. (I really should collect > my entire set of thoughts and notes on record types somewhere central …) If > you don’t require uniqueness, you don’t have a problem. I think style > proposed by SRFI 256 (and also used here) is a good sweet spot for SRFI > 9-style definitions: order-based correspondence in the sense of > bound-identifier=? is required between the field tags in the constructor > specification and the field tags in the accessor/mutator specification, > which offers the possibility of catching mistakes for the most common use > cases, but doesn’t otherwise imply that the field tags have anything more > than informative usefulness. > I remember that debate now. Using order only will preclude a pattern that I've used many times: I pick the order of arguments to the constructor to follow some clear pattern, but alphabetize the list of field definitions so that it's easy to find what I'm looking for later. Also, if they have to appear in the same order, what's the point of listing them in the constructor definition? They can be implicit.
