Re: propositions, oppositions, and some minor details

[Andre van Tonder <andre@xxxxxxxxxxxxxxxxx>]

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