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