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

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> Nevertheless, I went ahead with this change (after remembering that
>> wrapping the code in `ignore` should eliminate the extra warnings).
> So where does that leave us with the rx pattern?

It doesn't affect it directly, except in the fact that the old
definition would now also work for `pcase-let`.

> Perhaps it is; a proposed diff is attached below which treats zero and one
> variable specially and uses a list followed by immediate destructuring for
> >1 variables. (By the way, using a backquote form to generate backquote
> forms is annoying.)

Indeed, nested backquotes are painful.

> I now have, and am sad to say that a list is always faster for any practical
> number of N (I didn't bother trying more than 30) although the difference
> narrows as N grows. This is despite the destructuring code becoming
> considerably bigger for lists (as we get a long chain of tests and branches)
> than for vectors. It all boils down to vector construction being more
> expensive than lists.

Indeed, I think there's some optimization opportunities in our
implementation of vector construction.  We've already improved the
performance significantly compared to Emacs<24, but there's still room
for improvement.

>> I don't think it's much more complicated than your current constant
>> folding: when you see a let-binding of a variable to a *constructor*,
>> stash that expression in your context as a "partially known constant"
>> and then do the constant folding when you see a matching *destructor*.
>
> Doable, but definitely not low-hanging fruit. Since pcase has made a dog's
> breakfast of the destructuring code it's not straightforward to recognise it
> as such in the optimiser. Efforts needed elsewhere first!

I wasn't talking about pcase-generated code in particular.  But yes,
it'd probably need to be combined with more general rewritings like "let
associativity" in order to handle your particular case.  I think we'd
quickly get tired of scoping issues when doing that, so we'd want to
first change the representation to one where that's less problematic
(e.g. gensym all the lexical vars so we know there can't be any name
capture when we massage the code, also also clearly separate lexical
bindings from the dynamic bindings).

>> go back to the last option it tried and accept it even though it failed
>> to match.  It still sucks, but maybe it'll give someone else a better idea?
> Sounds like pcase--dead-end would fit then, at least as an internal name.
> Or pcase--Sherlock-Holmes.

Inspiring suggestions, thanks,


        Stefan