Daphne Preston-Kendal
Why I hate record types: a belated answer to @kitten_tech
Let’s first consider the opening paragraph of the Scheme reports. I truly believe the statement made by the first sentence: *all* programming languages should be designed by removing restrictions, rather than by feature piling.
I don’t think Scheme is unique in succeeding at following this philosophy, but I think it shares with only a few other languages the distinction of having achieved this goal.
Ludovic Courtès
@krans @dpk Very insightful, indeed.
Guix has developed a kitchen-sink syntactic record layer atop SRFI-9 (which is itself implemented in terms of Guile records). It has delayed and thunked fields, field value “sanitizers”, record “inheritance” (essentially functional setters), and more.
https://git.savannah.gnu.org/cgit/guix.git/tree/guix/records.scm#n285
Peter Brett
@dpk This is very thought-provoking — thank you! Is it even _possible_ to have a single basic record abstraction that fits all use cases (or can be used to build all use cases), as you suggest? Some of the most basic criteria seem mutually exclusive, but maybe I just haven't thought about it for long enough…
Daphne Preston-Kendal
Maybe other Schemers have other ideas. I really want to find something where people can give themselves the high-level record type interface they want to have, not the inevitably-not-powerful-enough one we give them. That would be The Scheme Way.
So yeah. Record type systems suck; you’ll probably hate the one in R7-large, but don’t worry, I will too; I wish we could do something better, but this a circle that nobody has yet worked out how to square.
Signing off!
Daphne Preston-Kendal
There is one other option I’ve considered: providing a define-[something? not sure what to call it]-type which gives you a disjoint type whose field size is determined at instance construction time, not at type definition time.
This would let you implement subtyping yourself with near-native efficiency – only two problems:
1. you’d still need the bounds check although it’ll be pointless in 99.99% of cases
2. you still stomp the ability to do compile-time instantiation
Daphne Preston-Kendal
Unfortunately (for me), Scheme users and the others in the WG really want native support for subtyping. SRFI 256 is my attempt to find an inoffensive means of doing this as a minimal extension, but I think it fails: I’ll probably withdraw it rather than take it through to finalization.
Plus, even once we have subtyping, our commitment to transparent R6RS interoperability *probably* means it has to be the R6RS subtyping system, with its baked-in sealedness and opacity support. Grumble grumble
Daphne Preston-Kendal
Nonetheless, my personal preference remains that R7-large add should nearly nothing over its smaller brother, for this reason. Essentially, what this would give you is a ‘pick two of three’ scenario, where the three are maximum runtime efficiency/support for subtyping/portability between implementations. (Implementations could still provide their own native subtyping, of course.)
Daphne Preston-Kendal
Implementing something like subtyping does have a performance cost, alas, compared to if subtyping were natively supported: you have to store the field values in some kind of vector pointed at by one of the ‘real’ fields of a subtypeable record type, which is an extra indirection, extra allocation, extra memory usage, and a bounds check you can strictly do without. And while you’re at it, you *probably* stomp the compiler’s ability to optimize with compile-time record instantiation, sigh
Daphne Preston-Kendal
R7RS small went the other way, cleaning up SRFI 9 (although not quite enough), providing nothing but flat records with a fixed field structure, with none of the R6RS features – no procedural layer, no inspection, not even subtyping support!
Despite this, the R7RS small way has a surprising amount to recommend it. In particular, because it provides basically nothing apart from a disjoint type predicate and some slots, you *can* actually implement a more featureful type system on top of it.
Daphne Preston-Kendal
(At least if you’re not the maintainer of an entire Scheme implementation – if you are, you can do what you want, by just baking all these things into the core of your record system. But that’s the essence of feature-piling, and is not The Scheme Way.)
Daphne Preston-Kendal
R6RS chose a nice set of features – single inheritance plus the ability to disable it, opacity, nongenerativity, procedural inspection and type creation – and gave them a very nice syntactic interface and a not-much-worse procedural interface. Its design is easy for an implementation to provide with good efficiency, and it’s formally absolutely correct, even preserving encapsulation under subtyping in a nice way.
Unfortunately, attempts to add other features to it invariably run into problems.
Daphne Preston-Kendal
So it goes on and on. Record type system features are just really, bizarrely bad for composing poorly with one another: worse than anything else in PL design that I’ve experienced.
What’s a Scheme report working group to do?
Daphne Preston-Kendal
If you’ve been following me recently, you know where this is going: no matter what you do, even if you know the record structure of a parent type, you can’t access the record structure of an opaque subtype in order to, say, make a copy of the record. So record opacity shuts out the ability for users to implement, for example, functional field updaters themselves – no matter how useful it is in the cases where opacity actually helps.
Daphne Preston-Kendal
In the case that you truly control the record type and know it either won’t be subtyped, or you’ll be the one subtyping it, opacity is fine, and does indeed stop composition-breaking shenanigans like this.
But when we add features, we don’t just add them for the cases where they’re useful: we also have to consider the cases where they’re not useful.
Daphne Preston-Kendal
‘Oops, okay’, you think. ‘Well, I know I‘m never going to expose the record-type descriptor for this type, so I’ll just declare it (opaque #t). Then nobody outside my module can access the procedural record features and break the type check.’
Hang on, though – record type opacity is another feature! Have you thought about what you’re making harder by including that feature in your record type system?
Daphne Preston-Kendal
If you have what R6RS and SRFI 99 call ‘procedural’ and ‘inspection‘ layers, someone can go in through the back door and create a record constructor procedure or a field mutator procedure which doesn’t do the type check. So these two quite simple features – one very commonly provided by implementations, the other very commonly wished for by users – actually need to be baked into the core of the record type system, so new constructors and mutators also apply the type check.
Daphne Preston-Kendal
Let’s take one example on that page: type-checked fields. Well, surely you can implement *that* in terms of a simple record interface! SRFI 253 does it (define-record-type-checked)! Just make sure the constructor checks the type of all the fields when the record is created, and any mutation procedures check that the new value for a field also satisfies the type check. Easy, no?
Well …
Daphne Preston-Kendal
But it’s not only the sheer number of features, but their composition with one another. Ideally, if we were to follow the Prime Clingerism, we would have a nice, small, composable core system where people could add the features they want – much like they can use continuations, closures, and hygienic macros to fill in the gaps adding features to other parts of the Scheme language.
Daphne Preston-Kendal
I have a fun little list on the R7RS wiki of features that seem nice to have in a record system. Some of them are from R6RS, some from SRFIs, some from Scheme implementations, some from other Lisps.
The reason I made this page is *not* because I want to put them all in R7-large, nor even that I want to consider them all for R7-large, but to show how bloated record systems can become; to show why record types are a uniquely awful part of evolving a language like Scheme.
https://codeberg.org/scheme/r7rs/wiki/Record-system-features
Daphne Preston-Kendal
It’s at once an honour and incredibly daunting to be responsible for writing the report that sits under these words.
Granted, Scheme hasn’t always succeeded here: undelimited continuations have stuck around far, far too long for something which composes so poorly *with itself.*
When we consider new features for R7-large, this maxim comes up often. (Like any such maxim, it’s vague enough that it can end up being wielded by multiple sides of a debate, each accusing the others of betraying it.)
Ludovic Courtès
@dpk @krans Great that all this could be implemented on top of SRFI-9!
What’s missing though, and can hardly be added, is subtyping. Of the features listed on the wiki page you mention, that’s the one I would add.
SRFI-99 looks like a good compromise?
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.