Re: Attaching context info to an error

["João Távora" <joaotavora@gmail.com>]

On Thu, Dec 28, 2023 at 7:22 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> > Just see eglot.el and jsonrpc.el for examples.  It's a constructor
> > in the C++ style.  Meaning the client of the library, when making
> > an object, won't get just a bunch of data.  They will either
> > get a fully functioning object _or_ an error.  You can't do that
> > in plain Elisp without "-init" custom constructors, just as
> > you can't do that in C without foo = (Foo*)malloc() + init_foo(foo).
>
> Not sure where using a "smart constructor" function (what you call
> "-init" custom constructor) is less work than defining
> a `initialize-instance` method.

That's right!  It isn't, it's more work, and more dangerous because
you will forget when to call it.

> > Furthermore, just like in typical OO, derivation of such classes
> > are guaranteed to have the base class parts valid and constructed
> > in their `intialize :after` this is the bread and butter of CLOS,
> > and it's awkward and error-prone to program without it.
>
> Ah... I think I'm beginning to see why I don't see the benefit: in my
> world, objects are basically immutable, so an object that's partly
> initialized (as in your "have the base class parts valid") is just
> already very weird :-)

It's not weird.  If D derived from B then the object that is passed
to the derived mode's contructor is already a fully functioning B.
This is exactly as in C++ where at least that part is bullet proof.
Not so in C and plain Elisp where allocation is one thing and
initialization another thing.

> > Right, it's because I _know_ that you wrote these things that I find
> > it odd you do now see how useful they are.
>
> There's a difference between knowing how to build a car and being
> a good driver, yes.
>
> I can write a Prolog interpreter but my Prolog programming skills suck.
> Similarly, I'm more comfortable using Haskell-style type classes (or
> the closely related C++ templates) than "classic OOP" with subtyping.

Many modern C++ template tricks are done using inheritance,
std::tuple comes to mind.  "Classic OOP" is about runtime
polymophism/virtual dispatch and yes it's seen better days
in the systems programming world, because the indirection
usually trashes caches and double dispatch is silly hard.

But for sporadic exceptions/conditions with objects generic functions
that to multiple dispatch beautifully?  I'd be hard pressed to
see better than what CL has.

> >> Redefinition of a class is definitely not currently supported (with no
> >> plan to support it in the foreseeable future).
> > In this case, it was a new version of jsonrpc.el that has to
> > be backward compatible to clients programming against the older
> > version.
>
> Then your bug report would be a feature request, I guess.

It's a bug inasmuch as EIEIO purports to be a port of CLOS,
where it's easy to do.

I don't need any class redefinition support.  The recipes
I gave earlier would be easy to replicate even if both CL
didn't support such trivial things.

> E.g. include a small patch to `jsonrpc.el` showing the code
> you would *like* to use.

I'd just like to remove the horrible slot-missing hack, it's
clearly marked in jsonrpc.el, just search for "Yuck!".

> > CLOS class redefinition is big business indeed, but just removing
> > a slot here in the same image worked nicely here for demonstration
> > purposes: it still errored as reassuringly as it would have if in
> > another Emacs session.
>
> Yes, I'm aware of this.
> But ELisp is a fairly limited "programming system" (as opposed to
> programming language", see doi:10.1145/2384592.2384611).
>
> I'm a PL guy and one from the functional programming side (i.e. averse
> to mutation) to boot, so redefining the classes of existing objects
> makes my head hurt.

Mine too, in fact in many years of CL I've not seen a single
case of useful CHANGE-CLASS.  But Emacs and Lisp machines are
designed as object landscapes mutating all the way.

Anyway, this is all besides the point: that protocol has nothing
to do with the current limitations of EIEIO's initialize-instance,
and even those limitations are quite small in comparison to the
benefits.

I see you've snipped all the rest of the "where to keep
the context" discussion.  Does that mean that my answer of
"stack _is_ the context, unwind only when absolutely done with it"
is satisfactory?  Did you understand how a standard named
restart for reporting byte compiler errors could be invoked
from "up above"?

What object exactly goes into the handler bind handlers?  Is
it the funny cons?  Can we at least get some generic functions
to hide that representation so that we can change it later on?

João