Unintentional conflict in define-immutable-type?

Unintentional conflict in define-immutable-type?

[Rob Browning]

This crashes in 2.0:

  (use-modules (srfi srfi-9 gnu))

  (define-immutable-record-type foo
    (foo x)
    foo?
    (x x))

  (foo 1)

like this:

  foo.scm:10:9: In procedure #<procedure 131fd00 ()>:
  foo.scm:10:9: In procedure make-struct: Wrong type argument in position 1: #<procedure %foo-procedure (x)>

Changing the type name to <foo> (or even xfoo) fixes the conflict, even
though "define-immutable-type foo" actually creates a binding for <foo>,
not foo.

I thought there was a chance this might be unintentional.
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Re: Unintentional conflict in define-immutable-type?

[Mark H Weaver]

Hi Rob,

Rob Browning <rlb@defaultvalue.org> writes:

> This crashes in 2.0:
>
>   (use-modules (srfi srfi-9 gnu))
>
>   (define-immutable-record-type foo
>     (foo x)
>     foo?
>     (x x))
>
>   (foo 1)
>
> like this:
>
>   foo.scm:10:9: In procedure #<procedure 131fd00 ()>:
>   foo.scm:10:9: In procedure make-struct: Wrong type argument in position 1: #<procedure %foo-procedure (x)>

The problem is that (define-immutable-record-type foo ...) binds 'foo'
to the record-type-descriptor (rtd), and you are also binding 'foo' to
the constructor.  I suppose we should try to improve the error message
in cases like this.

> Changing the type name to <foo> (or even xfoo) fixes the conflict,

Right.

> even though "define-immutable-type foo" actually creates a binding for
> <foo>, not foo.

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.

     Regards,
       Mark

Re: Unintentional conflict in define-immutable-type?

[Ludovic Courtès]

Rob Browning <rlb@defaultvalue.org> skribis:

> This crashes in 2.0:
>
>   (use-modules (srfi srfi-9 gnu))
>
>   (define-immutable-record-type foo
>     (foo x)
>     foo?
>     (x x))
>
>   (foo 1)
>
> like this:
>
>   foo.scm:10:9: In procedure #<procedure 131fd00 ()>:
>   foo.scm:10:9: In procedure make-struct: Wrong type argument in position 1: #<procedure %foo-procedure (x)>
>
> Changing the type name to <foo> (or even xfoo) fixes the conflict, even
> though "define-immutable-type foo" actually creates a binding for <foo>,
> not foo.

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.

The convention is indeed to use <foo> for the RTD.

HTH,
Ludo’.

Re: Unintentional conflict in define-immutable-type?

[Rob Browning]

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

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

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 could just use goops classes, but I was interested in immutability,
and at the moment they don't appear to support it.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Re: Unintentional conflict in define-immutable-type?

[Rob Browning]

Ludovic Courtès <ludo@gnu.org> writes:

> The convention is indeed to use <foo> for the RTD.

...and so (just to clarify) the goops class for a record is supposed to
be <<foo>> by default, and you'd need to (define <foo> <<foo>>) yourself
afterward, if you wanted the goops class to appear more conventional?

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Re: Unintentional conflict in define-immutable-type?

[Ludovic Courtès]

Rob Browning <rlb@defaultvalue.org> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> The convention is indeed to use <foo> for the RTD.
>
> ...and so (just to clarify) the goops class for a record is supposed to
> be <<foo>> by default, and you'd need to (define <foo> <<foo>>) yourself
> afterward, if you wanted the goops class to appear more conventional?

Yes, I’m afraid.

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> ,use(srfi srfi-9)
scheme@(guile-user)> ,use(oop goops)
scheme@(guile-user)> (define-record-type <foo>
		       (make-foo x)
		       foo?
		       (x foo-x))
scheme@(guile-user)> <foo>
$2 = #<record-type <foo>>
scheme@(guile-user)> <<foo>>
$3 = #<<class> <<foo>> 1c4b960>
scheme@(guile-user)> (eq? <foo> <<foo>>)
$4 = #f
--8<---------------cut here---------------end--------------->8---

The proxy class is created by ‘make_class_from_symbol’ in
libguile/goops.c (in 2.0.)

Ludo’.

Re: Unintentional conflict in define-immutable-type?

[Mark H Weaver]

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

Re: Unintentional conflict in define-immutable-type?

[Rob Browning]

Ludovic Courtès <ludo@gnu.org> 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 close enough attention.

If I really do want to have <foo> for the goops class, and don't want to
patch things up afterward, I could also just rename the default
constructor, i.e.:

  (use-modules (srfi srfi-9 gnu))
  (use-modules (oop goops))

  (define-immutable-record-type foo
    (make-foo x)
    foo?
    (x x))

  (display foo) (newline)
  (display <foo>) (newline)

Whether or not that's a good idea is of course a different question...

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Re: Unintentional conflict in define-immutable-type?

[Rob Browning]

Mark H Weaver <mhw@netris.org> writes:

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

Ahh, right.

So I suppose if you want <foo> as the goops name, then you really do
just have to choose something other than foo for the constructor within
the module.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4