At Wed, 29 Sep 2004 08:56:59 -0400 (EDT), Andre van Tonder wrote:
>
> 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.

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 - implementations that want first class
record types are likely to already be using a robust OO system that
can handle immutable fields without a performance hit, and just fall
back on a runtime type error.

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

--
Alex