Re: Attaching context info to an error

[Stefan Monnier]

>> > Anyway, as Gerd suggested, I would suggest at least supporting
>> > EIEIO in this handler-bind.
>> Could you give some concrete examples of things you'd (be able to) do
>> with it?
> Just look at anyCL program that uses conditions, there are
> very many of them.  One of them is Snooze [1] which uses them
> to represent HTTP error codes.

But these use error objects throughout.
My question was about "at least supporting EIEIO in this handler-bind".

> First, we'd have to be able to `signal` such objects.  And then,
> CLOS is good :-) you get access to lots of existing useful protocols.
> initialize-instance, print-object, etc for free.

[ Not clear what `initialize-instance` would be used for.  I also don't
  think `print-object` would be super useful, but yes a generic
  function to compute the error message would be a natural use, tho
  currently we haven't even bothered to allow the `error-message` to be
  a function, so the non-object representation of errors doesn't seem
  to be what's holding us.  ]

More importantly, that doesn't tell me what new things we could do,
most importantly how to attach context info :-)

> 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`.


        Stefan