This page is part of the web mail archives of SRFI 57 from before July 7th, 2015. The new archives for SRFI 57 contain all messages, not just those from before July 7th, 2015.
On Wed, 29 Sep 2004, Alex Shinn wrote:
At Wed, 29 Sep 2004 08:56:59 -0400 (EDT), Andre van Tonder wrote:
I must have ovelooked it). Compile-time checking of field validity is one of the points of this SRFI. It can be done with high-level macros. The reference implementation does this.I can't think of a way to do this in syntax-rules if the name of the record-type itself is a first-class value. The reference implementation relies on the fact that the name is a macro. But this is a minor issue ...
You are correct, of course, although I can think of a workaround in the (nonstandard, but common) implementations of syntax-rules that treat define as a binding form. Just expand the record definition to
(define record-type ....first-class-value-here...) (define-syntax record-name (syntax-rules () ((record-name "type") record-type) ..........Here record-type is a hygienically introduced new temporary identifier, whose value can then be accessed via the macro invocation (record-name "type"). So you can have your first class value and your macro to do with as you please.
I like the current solution where the "mutability flag" is simply whether there is a third element in the field spec (either setter or #f). Otherwise things can become too wordy. This does not exclude future usage of keyword arguments for other attributes.But if you make future extensions then the current design has no way to specify immutability. Once you add a fourth element, there will always be a third element.
This will not be a problem if additional extensions are all keyword attributes, which the current design would require.