Alex,

Thank you for your comments:

On Tue, 21 Sep 2004, Alex Shinn wrote:

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

I hear you, but if one wanted to make trouble, one could also argue the
opposite - that mutability does not even really belong in a records
specification.  Mutability is arguably an orthogonal concept from
records.  Indeed, one could have made all fields immutable, simplifying
the interface considerably, without losing any expressive power, since
mutable fields could then be simulated a la ML by simply storing boxed
data (e.g. a pair) in a field, as the reference implementation implicitly
does.

Of course, tradition and backwards compatibility forces us to include the
concept of updatable fields.  But I might point out that SRFI-9
does implicitly have immutable fields, even though it is not stated in so
many words.

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

There does not need to be any performance hit, since checking for
immutability can and should be done, as it is in the reference
implementation, at compile time.  Indeed, update! will give a compile-time
error if a field does not support the update!.

In a closure-based implementation such as the reference implementation, it
turns out to be mutable fields that are slower, since they have to be
unboxed at each access.  In an unoptimized vector-based approach, there
should be no performance difference between mutable and immutable fields.
When compiler optimizations are taken into account, immutable fields may
be faster.

There are of course further advantages to being able to specify
immutability, related to compiler optimizations, type inference, enforcing
of abstractions, and so on.

> 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 will amplify the section in the specification that states that this is
an error.

Regards
Andre