Re: pcase map binding form expansion failure on Emacs 27 only

[Adam Porter]

Kevin Vigouroux via "Emacs development discussions."
<emacs-devel@gnu.org> writes:

> Your patch is not included in the latest Emacs release (27.2). So, the
> macro expansion works as expected.

I am not using the version of map.el included with Emacs 27.2.  As I
wrote in the original message:

>> I confirmed that this happens even though map.el is installed at version
>> 3.1, and even though that version is actually loaded, by using this form
>> in the file:
>>
>>   (eval-when-compile
>>     (save-excursion
>>       (message "MAP VERSION IS: %S"
>>                (package-desc-version (car (alist-get 'map package-alist))))
>>       (message "MAP IS AT: %S"
>>                (locate-library "map"))
>>       (message "EXPANSION TEST: %S"
>>                (macroexpand-all '(pcase-let* (((map :max-width) plist))
>>                                    max-width)))))
>>
>> Which produces output like (using my makem.sh script[0], which I use for
>> linting and testing Emacs packages locally and on CI):
>>
>>   LOG (2021-09-07 11:31:03): Compiling file: bufler-workspace.el...
>>   MAP VERSION IS: (3 1)
>>   MAP IS AT: "/tmp/tmp.cEPHlNUWYk/27.1/elpa/map-3.1/map.elc"
>>   EXPANSION TEST: (let* ((x6 (map-elt plist ':max-width))) (progn max-width))
>>   Eager macro-expansion failure: (void-variable max-width)
>
> It seems to me that the `eval-when-compile' code is wrong. 

How is it wrong?  The purpose of that code is to output a debug message
when the file is being compiled, which it does.

> What does the compiler really generate?

It generates an incorrect macro expansion, which causes the eager macro
expansion/void-variable errors which precipitated this thread.

> #+begin_src emacs-lisp
> (defvar plist (list :max-height 3 :max-width 2))
>
> (eval-when-compile
>   (message "EXPANSION TEST: %S"
>          (macroexpand-all '(pcase-let* (((map :max-width) plist))
>                              max-width))))
> #+end_src
>
> #+begin_src emacs-lisp
> ;; Load the latest version of the `map' library (v3.1)
> ;;  located in the Download directory.
> (load-file "~/Downloads/map.el")
>
> ;; Byte-compile the sample test stored in the file
> ;;  /tmp/sample.el
> (byte-compile-file "/tmp/sample.el")
>
> ;; Look at the compiled file
> (find-file "/tmp/sample.elc")
> #+end_src
>
> You can see in the compiled file that there is no instruction related to
> the macro expansion. Obviously, there is no message displayed when the
> byte-code interpreter runs the compiled code.

It is not intended for a message to be displayed at runtime.  That's why
it's in `eval-when-compile'.

> #+begin_quote
> ;ELC
> ;;; Compiled
> ;;; in Emacs version 27.2
> ;;; with all optimizations.
>
> ;;; This file uses dynamic docstrings, first added in Emacs 19.29.
>
> ;;; This file does not contain utf-8 non-ASCII characters,
> ;;; and so can be loaded in Emacs versions earlier than 23.
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>
>
> (defvar plist (list :max-height 3 :max-width 2))
> #+end_quote
>
> So, I think that you have mixed things up when testing.

I'm not sure you understand the problem I'm describing.  Please see my
original message.

>> Even though I submitted the (very small) patch to map.el that added
>> support for the (map :KEYWORD) binding form, I finally had to give in
>> and apply a workaround in my package, using this binding form instead:
>>
>>   ((map (:face face) (:max-width max-width)) plist)
>>
>> That form correctly expands on Emacs 26.3, 27, and 28.0.50.  So at least
>> I won't get any more bug reports about this problem on my package.
>>
>> But I would like to understand what's going on here, if possible.  I'm
>> pretty sure that there's no bug in my code: my the package depends on
>> map 3.1, that version gets installed before my package does, that
>> version is loaded before my package is compiled, and my package does
>> (require 'map).  I can't find any reason for it to only fail on Emacs
>> 27.  And since it's not only happening in my testing, but in the wild,
>> something certainly seems fishy.
>
> Looking at things again, I'm not sure that imposing a given version for
> a package is a good thing.

I don't know what you mean by "imposing a given version for a package."
The "Package-Requires" header instructs package.el to ensure that
certain dependencies are installed at certain minimum versions.  This is
a standard practice in Emacs packages.