On 9 Feb 2025, at 00:29, Arthur A. Gleckler <xxxxxx@speechcode.com> wrote:

> This is fascinating. As I read it, it reminded me of capabilities-based security, which is a great model, so I was pleased to see that your acknowledgments mentioned JAR's work. My office was just down the hall from his while he was working on that thesis. I remember being amazed at how clean and clever those ideas were. I'm not surprised that Christine suggested the idea. After all, Spritely Institute is all in on capabilities, too.

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).

> In the description of define-record-type, you say "There is no requirement that field tags be unique…" You don't specify how constructor clauses are specified, but I'm assuming that they work as in SRFI 9. But if field tags aren't required to be unique, won't you run into conflicts because procedures can't have more than one argument with the same name?

I think this is based on an assumption that define-record-type is implemented as a syntax transformation to some lower-level form, where the constructor specification has a fairly basic correspondence to a procedure definition. If you want to do this, you can just use generate-temporaries to generate a new set of identifiers to be used as the arguments for the procedure definition for the constructor. (Or, if you do want to restrict yourself to what can be done in syntax-rules, a basic identifier-generating recursive expansion – note some recursive expansion is probably needed for *any* syntax-rules implementation of SRFI 9, to handle the accessors and mutators, so it’s just a matter of adding a generated identifier to each clause and generating the constructor definition last instead of first.)

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.

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.

> Later, you say "There must be at least as many fields in the constructor clause and field clauses as the total number of fields in the ancestor types." Must the names of the ancestor's fields match those in the ancestor's type definition, or is order how they are matched? To prevent confusion, I recommend the former.

Again, there is an inherent problem here. I don’t like the way d-r-t subtypes specify their parents’ fields at all (in the current turtle-records design); extending SRFI 9-style record definitions in this way is one of the biggest inherent problems in that design, imo. SRFI 99 offered a solution but it does depend on requiring each layer of the inheritance hierarchy to have unique field names, and to correctly refer to the names of corresponding fields of parent types. The problem here is demonstrated by the succession of SRFIs (131, 136, 150) trying to solve it in different ways.

> "Newly created" should not be hyphenated because "newly" is an adverb that ends in "ly."

Thanks!

> I look forward to the SRFI.

If it makes it that far. This is about my third or fourth attempt (including SRFI 256) in the direction of finding the minimal set of record system features which allows both efficiency and correct composition of desirable higher-level features with one another – without bloating the core record system itself with direct support for all of those individual features. We’ll see if I eventually notice some fatal flaw in this idea, too …

Daphne