At Thu, 30 Sep 2004 09:38:01 -0400 (EDT), Andre van Tonder wrote:
>
> >> I like the current solution where the "mutability flag" is simply whether
> >> there is a third element in the field spec (either setter or #f).
> >> Otherwise things can become too wordy.  This does not exclude future usage
> >> of keyword arguments for other attributes.
> >
> > But if you make future extensions then the current design has no way
> > to specify immutability.  Once you add a fourth element, there will
> > always be a third element.
>
> This will not be a problem if additional extensions are all keyword
> attributes, which the current design would require.

Let's suppose we want a type: extension (useful for uniform record
types).  If you had an existing immutable field

  (define-record-type color make-color color?
    (red red)
    (green green)
    (blue blue))

and added type info

   (red red type: <uint8>)

how does it know that type: is not the name of the setter?

You could break from the style of keyword lists traditionally used
here and have

  (red red (type: <uint8>))

so it knows keywords begin with the first parenthesized expression.
This also makes it easier to have keywords with zero or multiple
arguments, like (range: 0 255).

Either way, I think somehow or other we can always extend the current
syntax.  Even with Olin's original complaint about wanting the fields
grouped in parens for extensions, his example was adding methods, but
we could add methods by using an argument list instead of a field name

  (define-record-type color make-color color?
    (red red)
    (green green)
    (blue blue)
    ((invert self)
     (make-color (- 255 (red self))) (- 255 (green self)) (- 255 (blue self))))

--
Alex