Re: GOOPS-based SRFI-35 implementation

[Andreas Rottmann <a.rottmann@gmx.at>]

Neil Jerram <neil@ossau.uklinux.net> writes:

> Hmm.  My inclination is that it would be nicer if a compound condition
> straightforwardly satisfied is-a? for all its component condition type
> classes (without specialization of is-a?).  
>
> The big benefit of this is that methods defined for the component
> types will work on (instances of) the compound type as well, which
> makes sense because we know that the compound type has all the slots
> of the component type.
>
> The possible problem is that `make-compound-condition' would have to
> construct an appropriate subclass on the fly, and that this should
> interact nicely with compound condition classes created explicitly by
> the programmer, e.g.:
>

> (define-class &my-condition (&i/o-condition &runtime-condition)
>   ...)
>
> In other words, given this define-class, the result of
>
> (make-condition &my-condition ...)
>
> should be indistinguishable from that of
>
> (make-compound-condition &i/o-condition (...)
>                          &runtime-condition (...))
>  
I think you mean condition instead of make-compound-condition here.

> but I think this is achievable.
>
It may be, but this probably involves "caching" defined (via
define-class or the condition macro) condition types by their
supertypes. This, in turn, disallows defining different define-class
statements specifiying the same supers (if the supers are conditions).

Another, much more serious problem is the following:

(define-condition-type &c &condition
  c?
  (x c-x))

(define-condition-type &c1 &c
  c1?
  (a c1-a))

(define-condition-type &c2 &c
  c2?
  (b c2-b))

(define v2 (condition (&c2 (x "V2") (b "b2"))))
(define v3 (condition (&c1 (x "V3/1") (a "a3"))
                      (&c2 (b "b3"))))
(define v5 (make-compound-condition v2 v3)) ;; This is hairy

Here, we given your proposed model, we'd get this hierarchy:

(define-class &c ())
(define-class &c1 (&c))
(define-class &c2 (&c))
(define-class &c3 (&c1 &c2)) ;; Class constructed for v3
(define-class &c5 (&c2 &c3)) ;; Class constructed for v5

This will cause GOOPS to barf: "merge-lists: Inconsistent precedence graph"

I didn't see an obvious solution to this problem.

Andy
-- 
Andreas Rottmann         | Rotty@ICQ      | 118634484@ICQ | a.rottmann@gmx.at
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Make free software, not war!


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user