Re: Unintentional conflict in define-immutable-type?

[Mark H Weaver <mhw@netris.org>]

Rob Browning <rlb@defaultvalue.org> writes:

> Mark H Weaver <mhw@netris.org> 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 <foo> is bound to anything by it.
>
> I imagine it's actually goops that's doing it.
>
> Try using "define-immutable-type <foo>" and then add a (display
> <<foo>>).

I did, and I found that <<foo>> was unbound.  However, I see now that if
GOOPS is loaded, <<foo>> does indeed become bound to a class.  I find
this a bit unsettling to be honest, but I stand corrected.  Thanks :)

> That's what prompted my original post, I thought it might be handy to be
> able to use define-immutable-type (and the other record definitions) to
> create "normal" goops class names.
>
> So that you can have:
>
>   (define-immutable-type foo ...)
>   (define-method (bar (x <foo>)) ...)

You can do this if you pick a different name for the constructor.

However, I agree that it would be nice to allow the class to be named
<foo> and the constructor to be named foo.  The first idea that comes to
mind is to provide an optional extension to the 'define-record-type' and
'define-immutable-record-type' syntax to explicitly give the name of the
class.  Then you could name the RTD something like :foo and still name
the class <foo>.

> instead of only supporting:
>
>   (define-immutable-type <foo> ...)
>   (define-method (bar (x <<foo>>)) ...)
>
> Of course you can always just:
>
>   (define <foo> <<foo>>)
>
> afterward, but that's not quite right.

I guess that wouldn't work.  After (define-immutable-type <foo> ...),
it's important that <foo> remain bound to the RTD in the module where
'define-immutable-type' was evaluated.  The other procedures defined by
'define-immutable-type' refer to <foo> and rely on it being bound to the
RTD.

      Mark