goops method defined only in derived classes fails to become generic?

goops method defined only in derived classes fails to become generic?

[Jan Nieuwenhuizen]

[-- Attachment #1: Type: text/plain, Size: 283 bytes --]

[sorry moderator, sent from non-subscribed address]

Hi,

This worked with guile 1.8.  Bug or feature?

Greetings,
Jan

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  


[-- Attachment #2: class.tar.gz --]
[-- Type: application/x-compressed-tar, Size: 523 bytes --]

goops method defined only in derived classes fails to become generic?

[Jan Nieuwenhuizen]

[-- Attachment #1: Type: text/plain, Size: 226 bytes --]

Hi,

This worked with guile 1.8.  Bug or feature?

Greetings,
Jan

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

[-- Attachment #2: class.tar.gz --]
[-- Type: application/x-compressed-tar, Size: 523 bytes --]

Re: goops method defined only in derived classes fails to become generic?

[Andy Wingo]

On Wed 02 Feb 2011 14:34, Jan Nieuwenhuizen <janneke@gnu.org> writes:

> This worked with guile 1.8.  Bug or feature?

Do you have a test case?

Thanks,

Andy
-- 
http://wingolog.org/

Re: goops method defined only in derived classes fails to become generic?

[Jan Nieuwenhuizen]

[-- Attachment #1: Type: text/plain, Size: 390 bytes --]

Andy Wingo schreef op vr 11-02-2011 om 16:39 [+0100]:
> On Wed 02 Feb 2011 14:34, Jan Nieuwenhuizen <janneke@gnu.org> writes:

> Do you have a test case?

It was in the attached tarball, I'm attaching the individual files.

Jan

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

[-- Attachment #2: use.scm --]
[-- Type: text/x-scheme, Size: 195 bytes --]

#! /bin/sh
# -*- scheme -*-
exec guile --debug -L $(dirname $0) -s $0 "$@"
!#

(use-modules
 (oop goops)
 (base)
 (impl-a)
 (impl-b)
 )

(define obj (make <impl-a>))

(func obj)

(func-impl obj)

[-- Attachment #3: impl-b.scm --]
[-- Type: text/x-scheme, Size: 322 bytes --]

(define-module (impl-b)
  #:use-module (oop goops)
  #:use-module (base)
  #:export (<impl-b>
	    func-impl)
  #:re-export (func))

(define-class <impl-b> (<base>))

(define-method (func (self <impl-b>))
  (format #t "<impl-b>: func\n"))

(define-method (func-impl (self <impl-a>))
  (format #t "<impl-a>: func-impl\n"))

[-- Attachment #4: impl-a.scm --]
[-- Type: text/x-scheme, Size: 322 bytes --]

(define-module (impl-a)
  #:use-module (oop goops)
  #:use-module (base)
  #:export (<impl-a>
	    func-impl)
  #:re-export (func))

(define-class <impl-a> (<base>))

(define-method (func (self <impl-a>))
  (format #t "<impl-a>: func\n"))

(define-method (func-impl (self <impl-a>))
  (format #t "<impl-a>: func-impl\n"))

[-- Attachment #5: base.scm --]
[-- Type: text/x-scheme, Size: 175 bytes --]

(define-module (base)
  #:use-module (oop goops)
  #:export (<base>
	    func))

(define-class <base> ())

(define-method (func (self <base>))
  (format #t "<base>: func\n"))

Re: goops method defined only in derived classes fails to become generic?

[Andy Wingo]

Hi,

On Wed 02 Feb 2011 14:34, Jan Nieuwenhuizen <janneke@gnu.org> writes:

> This worked with guile 1.8.  Bug or feature?

Bugs, bugs, bugs!  The files were:

>   [5. text/x-scheme; base.scm]...
>
>   (define-module (base)
>     #:use-module (oop goops)
>     #:export (<base>
>   	    func))
>
>   (define-class <base> ())
>
>   (define-method (func (self <base>))
>     (format #t "<base>: func\n"))
>
>   [4. text/x-scheme; impl-a.scm]...
>
>   (define-module (impl-a)
>     #:use-module (oop goops)
>     #:use-module (base)
>     #:export (<impl-a>
>   	    func-impl)
>     #:re-export (func))
>
>   (define-class <impl-a> (<base>))
>
>   (define-method (func (self <impl-a>))
>     (format #t "<impl-a>: func\n"))
>
>   (define-method (func-impl (self <impl-a>))
>     (format #t "<impl-a>: func-impl\n"))
>
>   [3. text/x-scheme; impl-b.scm]...
>
>   (define-module (impl-b)
>     #:use-module (oop goops)
>     #:use-module (base)
>     #:export (<impl-b>
>   	    func-impl)
>     #:re-export (func))
>
>   (define-class <impl-b> (<base>))
>
>   (define-method (func (self <impl-b>))
>     (format #t "<impl-b>: func\n"))
>
>   (define-method (func-impl (self <impl-a>))
>     (format #t "<impl-a>: func-impl\n"))

Note that here we have a typo I think (<impl-a> instead of <impl-b>);
this should not have worked in either, but it was working in 1.8 for a
reason I will get to in a minute.

>   [2. text/x-scheme; use.scm]...
>
>   #! /bin/sh
>   # -*- scheme -*-
>   exec guile --debug -L $(dirname $0) -s $0 "$@"
>   !#
>
>   (use-modules
>    (oop goops)
>    (base)
>    (impl-a)
>    (impl-b)
>    )
>
>   (define obj (make <impl-a>))
>
>   (func obj)
>
>   (func-impl obj)

This works in 1.8 because use-modules apparently has a bug in which
modules loaded from a use-modules form are loaded in reverse order.  So
the last binding wins, and it's the one from <impl-a>.  For some reason
the <impl-a> reference in the `func-impl' from impl-b.scm is never made;
I suspect related to some lazy expansion strangeness.  This bug is not
present in 2.0.

Now, if we fix the bug in impl-b.scm to refer to <impl-b>, in 2.0 the
error is that `func-impl' does not apply to objects of type <impl-a>.
OK, this is correct.  However, if instead of using use-modules we use
`define-module' with #:use-module forms, we meet a similar bug, in that
2.0's define-module imports the modules in reverse order, so we get the
`func-impl' from impl-a.scm, which does "work"; but wrongly!

Basically your test case had bugs, but they showed a very important bug
in guile 2.0's define-module, and a previously unknown one from 1.8.
I'm not going to fix 1.8, but I have fixed 2.0.

Thanks for the report,

Andy
-- 
http://wingolog.org/