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

Re: propositions, oppositions, and some minor details



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.

-- 
Alex