Re: Pattern matching on match-string groups #elisp #question

["Mattias Engdegård" <mattiase@acm.org>]

26 feb. 2021 kl. 20.38 skrev Stefan Monnier <monnier@iro.umontreal.ca>:

> BTW, I was thinking about making the optimization more conservative, so
> it only throws away the actual `if` but keeps the computation of the test:
[...]
> and it does fix the `pcase-let` problem with your original code.

Given the trouble I think we can defend not respecting side-effects in something as functional as pcase!

> It should macroexpand to something morally equivalent to:
> 
>    (cond ((not (stringp STR)) nil)
>          ((not (string-match "\\(?1:a*\\)" STR)) nil)
>          ((looking-at "^"")
>           (let* ((x1464 (match-string 1 STR)))
>             (let ((FOO x1464)) FOO))))

Oh dear... perhaps we should just go with the intermediate list (or vector) and suffer the small allocation penalty? (At least we should treat the case of a single variable specially, since no consing would then be necessary.)

My guess is that a vector may be faster than a list if there are more than N elements, for some N.
Should we use string-match-p when there are no variables bound in the rx clause?

>> Of course a sufficiently optimising compiler would eliminate the consing!
> 
> Indeed, and it's not a difficult optimization (at least if you can
> presume that this data is immutable).

Right, although we would need some more serious data-flow infrastructure first. It would be useful for pattern-matching two or more values at the same time.

>>> It's linked to the special undocumented pcase pattern `pcase--dontcare`
>>> (whose name is not well chosen, suggestions for better names are
>>> welcome)
>> 
>> pcase--give-up
> 
> Hmm... probably not much more explanatory than "dontcare".

Well, 'dontcare' suggests that anything would do and the value not being used, like '_', but that's quite misleading.

> I was thinking of `pcase--impossible` as well.

Yes, that looks acceptable. In any case, it isn't really a user-facing symbol, is it? Otherwise we'd need crystal-clear semantics (and lose the double dashes).