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

Re: propositions, oppositions, and some minor details

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, 29 Sep 2004 08:56:59 -0400 (EDT), Andre van Tonder wrote:
> On Tue, 28 Sep 2004, Alex Shinn wrote:
> > 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.
> Such an implementation should be non-conformant.  I will amplify the 
> specification to say that a compile-time error has to be signaled if one 
> attempts to update! an immutable field (it should have been in there but 
> I must have ovelooked it).  Compile-time checking of field 
> validity is one of the points of this SRFI.  It can be done with 
> high-level macros.  The reference implementation does 
> this.

I can't think of a way to do this in syntax-rules if the name of the
record-type itself is a first-class value.  The reference
implementation relies on the fact that the name is a macro.

But this is a minor issue - implementations that want first class
record types are likely to already be using a robust OO system that
can handle immutable fields without a performance hit, and just fall
back on a runtime type error.

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