Goops generic-functions and srfi-64 tests

Goops generic-functions and srfi-64 tests

[KAction]

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

Hello!

Recently I noticed, that srfi-64 `assert-equal` macro do not use
`equal?` that was redefinded via `define-method` in scope of invocation
of `assert-equal`. It means, that

	(define e1 (make <foo> #:x 2))
        (define e2 (make <foo> #:x 2))
        (equal? e1 e2) ;; Overloaded to return #t
	(assert-equal (make <foo> #:x 2) (make <foo> #:x 2)) ;; fails

Why it happens, is clear. Since scheme macros are hygienic, equal? in
expansion of `assert-equal` is sealed to refer to (@@ (srfi srfi-64)
equal?). I belive, in presence of goops, it would be nice add

	(define-syntax equal?
            (identifier-syntax (module-ref (current-module) 'equal?))

I do not see, what would it break, but maybe I am missing something?

PS. Please, keep me in CC.

--
Best regards, Dmitry Bogatov <KAction@gnu.org>,
Free Software supporter, esperantisto and netiquette guardian.
GPG: 54B7F00D

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: Goops generic-functions and srfi-64 tests

[Ludovic Courtès]

KAction@gnu.org skribis:

> Recently I noticed, that srfi-64 `assert-equal` macro do not use
> `equal?` that was redefinded via `define-method` in scope of invocation
> of `assert-equal`. It means, that
>
> 	(define e1 (make <foo> #:x 2))
>         (define e2 (make <foo> #:x 2))
>         (equal? e1 e2) ;; Overloaded to return #t
> 	(assert-equal (make <foo> #:x 2) (make <foo> #:x 2)) ;; fails
>
> Why it happens, is clear. Since scheme macros are hygienic, equal? in
> expansion of `assert-equal` is sealed to refer to (@@ (srfi srfi-64)
> equal?).

No, that’s normally not a problem: (define-method (equal? ...) ...)
should turn the core ‘equal?’ primitive into a generic function, and
things would work well because (@@ (srfi srfi-64) equal?) is the same as
(@ (guile) equal?).

How exactly did you define ‘equal?’ methods?

Ludo’.

Re: Goops generic-functions and srfi-64 tests

[Dmitry Bogatov]

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

> > Recently I noticed, that srfi-64 `assert-equal` macro do not use
> > `equal?` that was redefinded via `define-method` in scope of invocation
> > of `assert-equal`.
> No, that’s normally not a problem: (define-method (equal? ...) ...)
> should turn the core ‘equal?’ primitive into a generic function, and
> things would work well because (@@ (srfi srfi-64) equal?) is the same
> as (@ (guile) equal?).

> How exactly did you define ‘equal?’ methods?
I define class object as

    (module-define! (current-module) '<struct-foo>
        (make <class> #:dsupers (list <object>) #:slots ...))

and after just

(define-method (equal? x y)
  ((@ (guile) equal?) x y))

(define-method (equal? (this <object>) (other <object>))
  (let* ((class_ (class-of this))
	 (slots (map car (class-slots class_))))
    (define (slot-values instance)
      (map (cute slot-ref instance <>) slots))
    (if (eq? class_ (class-of other))
	(false-if-exception (equal? (slot-values this) (slot-values other)))
      #f)))

I do not know, why first one `equal?` is needed, but otherwise guile
complained, that no method is present to compare two lists.

Interesting enough, I created simple module, and behaves as it should.
Maybe you have some wild guess about class being defined not via macro?

--
Best regards, Dmitry Bogatov <KAction@gnu.org>,
Free Software supporter, esperantisto and netiquette guardian.
GPG: 54B7F00D

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: Goops generic-functions and srfi-64 tests

[Daniel Llorens]

On 22 Nov 2014, at 18:00, guile-user-request@gnu.org wrote:

> Why it happens, is clear. Since scheme macros are hygienic, equal? in
> expansion of `assert-equal` is sealed to refer to (@@ (srfi srfi-64)
> equal?). I belive, in presence of goops, it would be nice add
> 
> 	(define-syntax equal?
>            (identifier-syntax (module-ref (current-module) 'equal?))
> 
> I do not see, what would it break, but maybe I am missing something?

SRFI-64 has all these specific binary predicates: test-eqv, test-equal, test-eq, test-approximate, but no way to pass your own predicate, which is annoying. Please correct me if I'm wrong.

An extension to be able to pass your own predicate may be more generally useful.

Re: Goops generic-functions and srfi-64 tests

[Taylan Ulrich Bayırlı/Kammer]

Daniel Llorens <daniel.llorens@bluewin.ch> writes:

> SRFI-64 has all these specific binary predicates: test-eqv,
> test-equal, test-eq, test-approximate, but no way to pass your own
> predicate, which is annoying. Please correct me if I'm wrong.
>
> An extension to be able to pass your own predicate may be more
> generally useful.

You can use `test-assert': (test-assert (my-equal? foo bar))


While we're on the topic, random remark on the SRFI-64 reference
implementation which Guile also uses: I'm working on it as part of my
R7RS SRFIs project[0] right now, and in some ways it's broken and
doesn't conform to its own specification.

The spec says that the default "simple" test runner logs to standard
output only, when the reference implementation has it write to a log
file.

`test-assert' doesn't evaluate its test-name argument on some Scheme
platforms (on Guile it's fine), and some `test-foo' forms evaluate their
test-name argument twice due to a typo in the code...

Overall the code is quite dirty so be wary of bugs.

I'm cleaning up and fixing the code on my repo as I go, while retaining
the `cond-expand' stuff for extra functionality on platforms supporting
it (most notably line number reporting), but I already ditched the file
logging (i.e. a significant behavioral change) so I don't know if Guile
will want to adopt it.

A Guile-specific from-scratch rewrite might not be a bad idea if
anyone's interested.

[0] https://gitorious.org/taylan-scheme/srfi/

Taylan

Re: Goops generic-functions and srfi-64 tests

[Daniel Llorens]

On 23 Nov 2014, at 14:47, Taylan Ulrich Bayırlı/Kammer <taylanbayirli@gmail.com> wrote:

> Daniel Llorens <daniel.llorens@bluewin.ch> writes:
> 
>> SRFI-64 has all these specific binary predicates: test-eqv,
>> test-equal, test-eq, test-approximate, but no way to pass your own
>> predicate, which is annoying. Please correct me if I'm wrong.
>> 
>> An extension to be able to pass your own predicate may be more
>> generally useful.
> 
> You can use `test-assert': (test-assert (my-equal? foo bar))

test-assert reports on the condition and not on the arguments, which is the point of having binary test-etc.

Re: Goops generic-functions and srfi-64 tests

[Ludovic Courtès]

Dmitry Bogatov <KAction@gnu.org> skribis:

> (define-method (equal? x y)
>   ((@ (guile) equal?) x y))

This really shouldn’t be needed, and I would even expect it to lead to
infinite recursion actually.

> (define-method (equal? (this <object>) (other <object>))
>   (let* ((class_ (class-of this))
> 	 (slots (map car (class-slots class_))))
>     (define (slot-values instance)
>       (map (cute slot-ref instance <>) slots))
>     (if (eq? class_ (class-of other))
> 	(false-if-exception (equal? (slot-values this) (slot-values other)))
>       #f)))
>
> I do not know, why first one `equal?` is needed, but otherwise guile
> complained, that no method is present to compare two lists.

Hmm, simply doing the following works for me:

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> ,use(oop goops)
scheme@(guile-user)> (define-method (equal? (a <object>) (b <object>)) 42)
scheme@(guile-user)> (equal? 1 2)
$1 = #f
scheme@(guile-user)> (equal? <class> <string>)
$2 = 42
--8<---------------cut here---------------end--------------->8---

> Interesting enough, I created simple module, and behaves as it should.
> Maybe you have some wild guess about class being defined not via macro?

What do you mean by “simple module”?

Thanks,
Ludo’.

Re: Goops generic-functions and srfi-64 tests

[Dmitry Bogatov]

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

> What do you mean by “simple module”?
Just example code, without any other possible interferring code.

--
Best regards, Dmitry Bogatov <KAction@gnu.org>,
Free Software supporter, esperantisto and netiquette guardian.
GPG: 54B7F00D

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]