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 Tue, 28 Sep 2004, Alex Shinn wrote:
In a straightforward implementation along the lines of SRFI-9 (or built on top of it), the type may be a first class value and without low-level macros you wouldn't have access to filed information at compile time. You would then need to check a mutability flag at runtime.
Such an implementation should be non-conformant. I will amplify the specification to say that a compile-time error has to be signaled if one attempts to update! an immutable field (it should have been in there but 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.
But I'm worried that the syntax is becoming hard to read and harder to extend. Specifically, if you have a normal mutable field (field-name) then later just add direct accessor (field-name getter) you've suddenly made the field immutable.
Good point. With compile-time checking, this becomes less of a problem. However, if people find these shorthands confusing, I can remove them. Let me know.
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.
Regards Andre