GNU bug report logs - #47992
27; 28; Phase out use of `equal` in `add-hook`, `remove-hook`

Previous Next

Full log

View this message in rfc822 format

From: Drew Adams <drew.adams <at> oracle.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, Daniel Mendler <mail <at> daniel-mendler.de>
Cc: "jakanakaevangeli <at> chiru.no" <jakanakaevangeli <at> chiru.no>, "47992 <at> debbugs.gnu.org" <47992 <at> debbugs.gnu.org>
Subject: bug#47992: [External] : bug#47992: 27; 28; Phase out use of `equal` in `add-hook`, `remove-hook`
Date: Sun, 25 Apr 2021 01:16:09 +0000

> >>> Perhaps `equal' can be fixed to do something better with closures?
> >>
> >> There's no magic: `equal` has to check the structural equality, so it
> >> has to recurse through the whole structure, including all the
> >> closed-over variables to which it refers.
> >
> > Well, structural equality on closures is an arbitrary choice. One
> > could simply refuse to compare closures structurally and treat
> > them as opaque objects.
> 
> Currently we could do that for byte-compiled closures
> but not for interpreted ones.

Also what I hinted at (I didn't know whether we might
in fact already do that), and why I spoke specifically
of supporting also interpreted code.

Emacs users often use Lisp as part of their interaction
with the editor, so: interpreted code.  Lose that and
we lose Emacs.  IMHO.

And what would we be losing it for?  Some performance
gain for closures used as hooks?  If you're convinced
of the need or desirability of such a change...

To be clear, by lose that I mean the ease of using Lisp
interactively, which today still means interpretation.

You'll say that you'll replace all interpretation by
on-the-fly jitty compilation...  That's also why I wrote
that hint about possibly doing something better with
closures wrt `equal'.  We're not there - not by a long
shot.  And doing what's been proposed here doesn't get
us there. 

> Equality on functions is fundamentally undecidable and it's nigh-on
> impossible to provide a sane and well-defined "approximation" of it
> either (at least not without significantly restricting the set of
> optimizations that the compiler can be allowed to perform).

100% agreement.  And there's no need for it, for Emacs.

> The upside is that this fundamental problem was the motivation for the
> development of type classes in Haskell which are a great feature
> (nowadays used in most proof assistants and in several other
> programming languages such as Scala and Rust).

Meanwhile, back at the Emacs ranch, for actual users...

(Not that a Haskell Emacs wouldn't be an interesting
project.  Please go for it.)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.