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, 22 Sep 2004 12:35:52 -0400 (EDT), Andre van Tonder wrote: > > 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 straightforward implementation along the lines of SRFI-9 (or built on top of it), the type may be a first class value and without low-level macros you wouldn't have access to filed information at compile time. You would then need to check a mutability flag at runtime. Even if the type is not first class you may have to deal with slot-ref which can't guarantee type. However, realistically most implementations either use a relative of TinyCLOS (for which slot-setting is customizable with the MOP and for immutable fields and left unchanged for mutable fields at no extra cost) or Meroon (which already supports immutable fields), so this isn't really an issue. But I'm worried that the syntax is becoming hard to read and harder to extend. Specifically, if you have a normal mutable field (field-name) then later just add direct accessor (field-name getter) you've suddenly made the field immutable. What you meant to do was change it to: (field-name getter #f) which is confusing. For more consistency you could make immutability a third positional parameter (field-name getter setter immutable?) with immutable? defaulting to #f, and you would supply #t to make it true. But immutability is just a special case of validation, which is a special case of a configurable/wrappable setter, which is handled efficiently in the TinyCLOS approach. I'm not at all suggesting we add these to this SRFI, but they should be considered potential future additions, which means we may have these and other attributes associated per field. At that point it may be worthwhile to switch to keyword-style field definitions: (field-name getter setter :immutable? #t) [not implying keywords, that parameter would be auto-quoted and the : is just for style] -- Alex