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