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: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>, "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: Sat, 24 Apr 2021 23:08:54 -0400

Drew, what does this rant have to do with add-hook?
Please stay focused.

The only relevant thing I saw in there was:

>> Equality on functions is fundamentally undecidable [...]
> 100% agreement.  And there's no need for it, for Emacs.

Huh, without it, there's no `remove-hook`.



        Stefan


Drew Adams [2021-04-25 01:16:09] wrote:
> 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.