On 01/03/2016 06:50 AM, David Kastrup wrote: > Daniel Colascione writes: > >> On 01/03/2016 06:07 AM, David Kastrup wrote: >>> Dmitry Gutov writes: >>> >>>> On 01/03/2016 11:02 AM, David Kastrup wrote: >>>> >>>>> Uh what? Whether pcase does not help with simple cases should have >>>>> little bearing on whether it helps with more complex cases. >>>> >>>> But it does. It takes less code, >>> >>> You mean, less input. >> >> A side effect of a more expressive system. >> >>>> and follows the common design of pattern matching, which isn't hard to >>>> understand and internalize. >>> >>> And yet Emacs has more than just regexp operations for dealing with >>> strings, and most string operations are carried out without reverting to >>> regexps. >>> >>>> In the more complex cases, the syntax may have some thorns, >>> >>> Then it's not doing a good job of reducing complexity. If it requires >>> me to use quasiquote for stuff that contains neither unquote nor >>> unquote-splicing (and has no sensible interpretation of unquote-splicing >>> in connection with its own use of quasiquote anyway), it does a bad >>> human interfacing job. Why do I need to quote self-quoting expressions >>> at all? And why do self-quoting symbols differ in meaning when preceded >>> by quasiquote? In Lisp, `nil is equivalent to nil . That's not what >>> pcase sees, I think. >> >> I find pcase quite readable; it's not going away. > > So it should not get fixed or made more consistent with expectations? > >> Honestly, I also found the existing documentation completely adequate. > > The problem is that its underlying design principle, matching quoted > stuff structurally/literally and using unquoted symbols as variable > names, is only implemented in a cursory manner. That means that reading > a pcase expression and understanding what it does does not enable you to > fix it with confidence or write your own. I find it adequately general --- much more so than, say, destructuring-bind. Do you have a concrete proposal?