Re: Attaching context info to an error

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

> It's not just initialize-instance, of course, it's CLOS or
> an equivalent.

You wrote:

    [...] And then, CLOS is good :-) you get access to lots of existing
    useful protocols.  initialize-instance, print-object, etc for free.

Which implies that `initialize-instance` is a useful protocol.
I'd just be happy to see a concrete example of something useful you can
do with it that's easier than what we do with "old style Lisp".

> Top of my head, CLOS gives you hierarchies easily, with generic
> functions doing the right thing by default when called with an
> instance of the subclass.

You do realize that I wrote `cl-generic.el`, made changes to
`cl-defstruct` to better integrate with EIEIO, ...

> That's the "standard method combination" [1],

... and this as well, right?

> *** Welcome to IELM ***  Type (describe-mode) or press C-h m for help.
> ELISP> (defclass foo () ((bar :initarg :bar) (baz :initarg :baz)))
> foo
> ELISP> (make-instance 'foo :bar 42 :baz 42) ; so far so good
> #<foo foo-156aec4e27b2>
> ELISP> (defclass foo () ((bar :initarg :bar))) ; redef
> foo

Redefinition of a class is definitely not currently supported (with no
plan to support it in the foreseeable future).

But in the `jsonrpc.el` there is no redefinition, so it seems to be
another problem.  Can you open a bug with a small recipe that
reproduces the problem that you encountered while writing `jsonrpc.el`?

> In summary, I think the "context" you are thinking about can just
> be good old dynamic context, i.e. let-bindings of special
> variables, with the new HANDLER-BIND-powered twist that these
> variables can remain private to their users _and_ be augmented
> after they are initially established.
>
> Right?  Wrong?

That describes where the context is placed until the error is signaled.
The question is how/where to preserve (part of) this context information
when some code wants to use it *after* unwinding the stack.

E.g. in `bytecomp.el` on the handler-bind branch I solved it as follows:

	      (let ((form-stack nil))
		(condition-case error-info
		    (handler-bind
		        ((error (lambda (_err)
		                  (setq form-stack byte-compile-form-stack))))
		      (funcall body-fn))
		  (error (let ((byte-compile-form-stack form-stack))
		           (byte-compile-report-error error-info))))))))

where `byte-compile-form-stack` is basically your *FOO-DATA*, and
I preserve/propagate this info by stashing it in the
`form-stack` variable.

Maybe we could have gotten away with calling `byte-compile-report-error`
directly from the `handler-bind` handler, but that could be affected by
all kinds of dynamic let-bindings and whatnot.

Another example is in the C code: when we call `signal`, the C code
walks the backtrace to find the name of the inner function, stores it in
the global `Vsignaling_function` and then uses it in
`cmd_error(_internal)` (i.e. after unwinding the stack) to include it in
the error message.  The us of a global var here is not just ugly but
it's also wrong because other ELisp code can be executed between the
moment we store the info in the var and the moment we use it, so it can
be polluted by the info from some other error.
[ And yes, we could rewrite that code to do something like what I did
  in `bytecomp.el` above.  ]

>> The upside doesn't seem worth the cost for now.
> It'll be harder 40 years from now.

I guess we'll see :-)


        Stefan