[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Can't compile `or' pcase pattern

From: Michael Heerdegen
Subject: Can't compile `or' pcase pattern
Date: Thu, 11 May 2017 18:04:00 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)


Stefan, probably,

I have found a problem while working on el-search:

The following form F:

#+begin_src emacs-lisp
 '(or (l ^ defstruct object)
      (l ^ (and (symbol "def") (or (pred macrop) (pred special-form-p))) 

should compile a lambda which contains a pcase form containing the given
`or' pattern:

#+begin_src emacs-lisp
(defun el-search--matcher (pattern &optional result)
   (let ((expression (make-symbol "expression")))
       (let ((byte-compile-debug t) ;make undefined pattern types raise an error
             (warning-suppress-log-types '((bytecomp)))
             (pcase--dontwarn-upats (cons '_ pcase--dontwarn-upats)))
         (byte-compile (lambda (,expression)
                         (pcase ,expression
                           (,pattern ,(or result t))
                           (_        nil)))))))))

where `el-search--with-additional-pcase-macros' just temporarily adds
some pattern definitions to the pcase macro environment.

The problem is that the call of `el-search--matcher' in F takes over one
minute of time and then gives up with

|  byte-compile-lapcode: Bytecode overflow

Similar cases also take extremely long also but don't cause an overflow.
AFAICT the expansion of the pattern does not produce extraordinarily
dumb code.

Even stranger: Calling `el-search--matcher' with any of the 2 patterns
inside the `or', i.e.,

#+begin_src emacs-lisp
 '(l ^ defstruct object))


#+begin_src emacs-lisp
 '(l ^ (and (symbol "def") (or (pred macrop) (pred special-form-p))) object))

instantly succeed.

Have I hit some weak point in the implementation of `pcase's `or'?  Is
there some way to avoid this problem?  Simplifying the semantics of `l'
seems to help a bit.  But I would like to understand what the problem is
and how I could avoid it.

This is on master, but with emacs-25 I see same issue.

Quitting with debug-on-quit -> t doesn't look like there is an infinite
recursion while compiling or code walking (though the recursion depth is
not small).

For reference I attach the macroexpansion of the pattern in F.  



Attachment: bug.el
Description: application/emacs-lisp

reply via email to

[Prev in Thread] Current Thread [Next in Thread]