GNU bug report logs - #59900
30.0.50; map pattern in pcase causes a byte-compile error

Previous Next

Full log

View this message in rfc822 format

From: Akira Komamura <akira.komamura <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 59900 <at> debbugs.gnu.org
Subject: bug#59900: 30.0.50; map pattern in pcase causes a byte-compile error
Date: Fri, 9 Dec 2022 16:58:28 +0900

[Message part 1 (text/plain, inline)]

On Fri, Dec 9, 2022 at 4:12 PM Eli Zaretskii <eliz <at> gnu.org> wrote:

> Thanks, but all this still doesn't answer my questions,
> unfortunately.  You-all are describing something that I cannot wrap my
> head around, because that basic question was not answered yet.
>
> Would someone please take me through the problem step by step?
>

There is a MELPA package depending on `pcase'. It contains a `map' pattern:

(pcase-let* ((`(,_name . ,(map filename outline-path id
front-context-string indirectp))
  ...)

The support for `map' pattern is not built into `pcase.el'. Instead, it is
enabled through `pcase--get-macroexpander', which is implemented as follows:

(defun pcase--get-macroexpander (s)
  "Return the macroexpander for pcase pattern head S, or nil."
  (get s 'pcase-macroexpander))

It returns `pcase-macroexpander' property of the symbol (i.e. `map' in this
case). The property should be available at compile time. If not, the library
will fail to byte-compile.

To set the property of an additional pattern, `rx', `map', `seq', etc. all
use
`pcase-defmacro'. I think autoloading the `pcase-defmacro' form in `map.el'
can
prevent the error as well as possible future errors in other libraries.
This is
already done in `rx.el'.

[Message part 2 (text/html, inline)]

Previous Next

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