Re: Attaching context info to an error

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> [ Not clear what `initialize-instance` would be used for.
> It is passed the keyword arguments that are passed to CL:ERROR
> or CL:SIGNAL [1,2].

Yes, I know, but that doesn't tell me what it lets us do that we can't
do right now.

> Though, I've noted before how our initialize-instance protocol
> is inferior: It takes slots as its second argument, whereas is
> should take initargs instead.  This makes changing the
> representation without changing the interface hard, but that
> can be worked around with the slot-missing protocol.

[ While Eric called it "slots" it holds the plist of initargs, just
  like the CLOS one.  The only difference I know is that CLOS passes it as
  an `&rest` arg.  You also told me that CLOS includes the "default" init
  args taken from the `defclass`, but I'm not familiar with
  those details (neither for CLOS nor for EIEIO).  ]

>> I also don't think `print-object` would be super useful,
> It's useful when printing the human-readable error message isn't
> appropriate say, because it takes multiple lines.

I'm not sure the difference qualifies as "super useful".
I don't mean to say we wouldn't be happy to be able to define ad-hoc
methods for `cl-print-object` of error objects, but it's much too minor
to motivate a change of representation.

>> More importantly, that doesn't tell me what new things we could do,
>> most importantly how to attach context info :-)
> You can modify a condition object like you can any other
> object.

I'm afraid that doesn't tell me how to attach context to an
error object.  The context I'm talking about are orthogonal to the error
objects themselves: any kind of context info could be attached to any
kind of error object.

I guess the only way this would help is if we had the foresight, when
designing the root class for error objects, to include a `context` slot
(even though it might go unused most of the time).
Is that what you had in mind?

>> > From a CL perspective, and even other languages, using our
>> > "error symbol with some 'error property" representation of
>> > errors is almost self-evidently inferior to just making it
>> > a first class object.
>>
>> You don't need to convince me of that, indeed.  But that's not what we
>> have right now, and it's not trivial to retro-fit it cleanly in the
>> current system.  Luckily, AFAICT it's orthogonal to `handler-bind`.
>
> AFAICT CL:HANDLER-BIND is aware of inheritance [3], i.e. the
> things you put in "type" of each handler binding in CL:HANDLER-BIND
> are interpreted as designators of subclasses of CL:CONDITION and
> dispatch similarly to generics.  That shouldn't be too hard
> to fit if we say `cl-condition` is the base class and
> `cl-error` and `cl-warning` are its children, etc.

What I mean is that if we start using something else than cons cells to
represent error objects, loads of code will break because of things like:

    (condition-case err
        ...
      (error ... (signal (car err) (cdr err))))


-- Stefan