At Wed, 15 Sep 2004 08:53:21 -0400 (EDT), Andre van Tonder wrote:
>
> Except that I was thinking of using the arity to determine whether the
> field was mutable or not (even in the absence of setters, thge
> distinction is important for update!).

OK, that's where I was confused, I was mentally grouping update! with
the pattern matching and assumed it would be separate.

However, even with update! I'm not sure we want to include the concept
of immutable fields.  Part of this is subjective - I don't like
restricting the programmer, especially at the expense of added
complexity; I think you should layer such restrictions on top of
simpler interfaces, leaving a choice in what the restrictions are and
how they work.  This viewpoint would suggest leaving immutability to a
separate SRFI, so that you could have alternatives such as the more
general idea of a "validated" field with type and range limits, etc.

More objectively I think immutability is too dependant on the
reference dispatch mechanism.  It is easy and fast with dispatch
closures, but most implementations are likely to want to define
SRFI-57 records in terms of their native objects, and others will
implement it using a vector-based approach.  With such an approach
checking for immutability adds a lot more complexity and is likely a
noticable performance hit.  For records efficient slot access is
crucial.

Further, immutability or any flag or meta-data associated with a field
brings up the issue of class precedence list.  If the same name field
is inherited from two different classes, one of which is mutable and
one of which is immutable, which does the child class inherit?  I
would definitely argue for the C3 linearization, but this may be more
detail than you want to go into in this SRFI.

--
Alex