Re: GOOPS-based SRFI-35 implementation

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

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

> Andreas Rottmann <a.rottmann@gmx.at> writes:
>
>> Neil Jerram <neil@ossau.uklinux.net> writes:
>> 
>> > Andreas Rottmann <a.rottmann@gmx.at> writes:
>> >
>> I've thought of this, too; this was my reason to use GOOPS in the
>> first place.
>
> Great - our thoughts are very much in sync then.  In my view, though,
> the whole idea becomes much nicer and more useful if we integrate it
> with existing Guile exceptions, so I hope we can agree with Marius to
> do this.
>
Indeed. Making Guile use SRFI-35 conditions everywhere would be a
*very* nice thing to have.

>> Also, there is a class &compound-condition which doesn't exist in
>> the SRFI (so methods for compund conditions can be defined).
>
> Seems sensible; also that it doesn't exist in the SRFI, because
> &compound-condition is not a condition _type_ (even though it does
> make sense as a GOOPS class).  Do you have an example in mind of how
> methods on &compound-condition can be useful?
>
I've so far only used it this way:

(define-method (handle-condition (c &compound-condition))
  (cond
   ((and (message-condition? c)
         (error? c))
    (format (current-error-port) "itla-debuild: ~A\n" (condition-message c))
    (if (abort-condition? c)
        (exit 1)))
   (else
    (format #t "itla-debuild: unexpected condition ~S\n" c))))


And then somewhere raise a fatal error:

      (raise
       (condition
        (&message
         (message (format #f "Current working directory ~S is not part of working copy build area ~S"
                          (getcwd) (string-join wc-area-dirs "/"))))
         (&abort)))

> I'm not sure though about `condition' expanding to
> `make-compound-condition' in the case there is only one type given.
> Is this implied in some way by the SRFI?  I think it would be nicer to
> detect the single type case and use `make-condition' instead.
>
Well, I detect that in make-compound-condition itself, but that's not
the most obvious place (since the name make-compound-condition implies
that a call will indeed result in a compund condition).

>> Plus, there is a macro guard/handle, which calls handle-condition:
>> 
>> (define-method (handle-method (&foobar-condition c))
>>  ...)
>> 
>> (guard/handle
>>   (some-code-that-maz-be-foobar))
>
> (Not in the version that you posted, so I presume this is newer.)
>
Yes, but it's in my Archive:

% tla register-archive http://people.debian.org/~rotty/arch/a.rottmann@gmx.at/2004-main
% tla get itla--devo--0.1 itla
% $EDITOR itla/srfi/srfi-35.scm

> Interesting.  I'm sceptical that it will be possible to define a
> generally useful handler for a condition, but I could easily be wrong,
> and there is negligible overhead from providing this.  (On the other
> hand, it's only a few lines, so perhaps could be left to the
> programmer to write for him/herself when needed?)
>
I think this might come handy for top-level handlers. If there is
general consensus, I could take this out of (srfi srfi-35), of course.

>> > by SRFI-35.  Therefore, for example, `make-condition' would create and
>> > return a GOOPS error/exception class and, given a
>> > error/exception/condition object OBJ, `(condition-has-type? OBJ TYPE)'
>> > would be identical to `(is-a? OBJ TYPE)'.
>> >
>> I'd have to specialize is-a? for this, since compound conditions all
>> share a class.
>
> 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,
>
That was my initial idea, I then however switched to a separate class
for some reason. "compound-condition-is-derived-class" seems like a
more coherent design to me now, however.

> 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 (...))
>  
> but I think this is achievable.
>
> This conflicts, though, with the introduction of &compound-condition
> and the idea that &compound-condition provides a way to define methods
> on compound conditions.  Since this ability is a Guile extension
> anyway (w.r.t. SRFI-35), I think it would be reasonable to say that
> the way to do this is to define the compound condition class
> explicitly, using define-class as just above.
>
Sounds like a good plan, I'll look into this.

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

If atheism is a religion, then health is a disease. -- Clark Adams


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