Re: Attaching context info to an error

[Stefan Monnier]

>> >> [ 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.
> I guess we can do everything with symbol and cons,

I don't mean "do" as in "Turing equivalent".
"less work" is a good thing to "do".  I just don't know in which way
`initialize-instance` lets one do less work.

> I'd guess the cl-averse are still doing structs with vectors :-)

I don't think I'm strongly "cl-averse", but I'm rather not familiar
enough with it to know its benefits.  Having modified some of its code
I'm familiar with its cost and what it does, but that doesn't
immediately translate into ideas for how I could make good use of it.

>> [ 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.
>
> Yes, but it's a big one.

I completely fail to see why.

> Our version will go looking for slots for that each initarg and if the
> slot doesn't exist it barfs, whereas in Common Lisp you can make it
> &accept-other-keys.

You lost me here.  How does that relate to `&rest` vs `not &rest`?

> I think I also wrote about this off list.  In CL, make-instance can
> be given arbitrary keyword args and they will show up in the
> initialize-instance.  They may or may not line up with a slot's
> initarg.

AFAIK the same thing holds for EIEIO's `initialize-instance`.

> This enables us to change the data representation while
> keeping the interface to the class.  See the current master's
> lisp/jsonrpc.el for an example where I had to use slot-missing to
> get around this.

I don't think this has anything to do with `&rest` or not.  It sounds
like a bug in `shared-initialize` or `initialize-instance` (or
a disagreement between the two).  I suggest you try and write a short
recipe for it and make it a bug report.

>> 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 don't know what "context" you are talking about (I guess it
> was in the initial email, but I couldn't grok it).

In different cases we may want to add contextual info about an error,
such as the time at which it was signaled, the backtrace, some subset of
the backtrace (e.g. just the name of the innermost function), or the
list of files we're in the middle of loading, or some node in
a datastructure within which we were operating when the error occurred,
...

Usually which info to collect will depend on what it will be used for,
so it's under the control of the outer code, and is thus orthogonal to
the error that's signaled.

>> 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))))
>
> Ugh indeed.  40 years of leaky abstractions, ¯\_(ツ)_/¯
>
> So yes, "error" err would have that poor man's cons.  Maybe
> condition-case would only catch those?  A new shiny
> handler-case  on the other hand, would catch proper richie
> rich errors (and have the better syntax).

That entails a heavy amount of churn to change old code to use that new
form (while we'd want to support both for backward compatibility, we'd
also want to slowly get rid of the old form to keep the overall
complexity in check).

The upside doesn't seem worth the cost for now.


        Stefan