This page is part of the web mail archives of SRFI 57 from before July 7th, 2015. The new archives for SRFI 57 contain all messages, not just those from before July 7th, 2015.
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.