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