[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why the inversion of mutability between make-rtd and define-record-type?

This page is part of the web mail archives of SRFI 99 from before July 7th, 2015. The new archives for SRFI 99 contain all messages, not just those from before July 7th, 2015.



Derick Eddington wrote:
> What is the rationale for making make-rtd's succinct identifier-only
> field spec mean mutability for the field instead of immutability?  This
> is a confusing mismatch with define-record-type's succinct
> identifier-only field spec which means immutability.

The rationale was conceptual compatibility with historical
precedents, but that is not compelling because conceptual
consistency within the SRFI itself counts for more.
Presumably a symbol should indicate an immutable field,
and a list with only one element should indicate a mutable
field.

> Also, why is a succinct field spec even justified for
> the procedural layer?

Some programmers prefer to use a procedural layer, and the
succinct field specs accomodate them.  There's no reason
for this SRFI to be biased for or against either layer,
in terms of convenience or otherwise.

One of the primary goals of this SRFI was to make the
procedural layer so compatible with the syntactic layer
that it just doesn't matter which layer was used to define
a record type.  That's where the R6RS design goes horribly
wrong.

Will