Mark H Weaver writes:
> I guess that wouldn't work. After (define-immutable-type ...),
> it's important that remain bound to the RTD in the module where
> 'define-immutable-type' was evaluated. The other procedures defined by
> 'define-immutable-type' refer to and rely on it being bound to t
Ludovic Courtès writes:
> This is expected. The macro, like that of SRFI-9, creates one binding
> for the record-type descriptor, one for the constructor, one for the
> predicate, and one for the accessor. Since the first two have the
> same name, it Doesn’t Work.
OK, so I just wasn't paying c
Rob Browning writes:
> Mark H Weaver writes:
>
>> I believe you are mistaken about that. Looking at both the code and the
>> expansion of your 'define-immutable-record-type' form above, I see no
>> evidence that is bound to anything by it.
>
> I imagine it's actually goops that's doing it.
>
>
Rob Browning skribis:
> Ludovic Courtès writes:
>
>> The convention is indeed to use for the RTD.
>
> ...and so (just to clarify) the goops class for a record is supposed to
> be <> by default, and you'd need to (define <>) yourself
> afterward, if you wanted the goops class to appear more con
Ludovic Courtès writes:
> The convention is indeed to use for the RTD.
...and so (just to clarify) the goops class for a record is supposed to
be <> by default, and you'd need to (define <>) yourself
afterward, if you wanted the goops class to appear more conventional?
Thanks
--
Rob Browning
