bug#20268: 25.0.50; pcase-lambda broken

[Leo Liu]

Forgive me to rely here. None of our messages shown up in bug#19670.

> After recent rewrite of pcase-lambda I am seeing:

> (cl-some (pcase-lambda (`[fullsweep_after ,v]) v)
>         '([min_bin_vheap_size 46422]
>           [min_heap_size 233]
>           [fullsweep_after 65535]
>
>           [minor_gcs 10]))
>
> Indeed, that's the semantics I chose.
> The previous semantics was for the function to do nothing and return nil
> if the arg doesn't match.  The new semantics is the same as the one used
> by pcase-let.  It's not without its fault of course, but at least it does
> correspond to the usual idea of "destructuring" and generates more
> efficient code.

I don't mind new semantics but I want to make sense of it so as to use
it with confidence. What I am seeing is:

(funcall (pcase-lambda (`[fullsweep_after ,v]) v) [min_bin_vheap_size 46422])

=> 46422

That doesn't make sense to me. Could you explain why this is the right
thing?

> I think if you prefer to return nil, then the macro should look like

>   (pcase-lambda ((`[fullsweep_after ,v]) v))

> which would then naturally let you add additional cases like

>   (pcase-lambda ((`[fullsweep_after ,v]) v)
>                 ((`[min_heap_size ,v]) (/ v 2)))

I didn't choose the multiple-clause version because it is a cheap
shortcut for (lambda (...) (pcase ... ...)).

The single-clause pcase-lambda makes a lot of higher-order functions fun
to use and that is where I am reaping the benefits.

> Admittedly, for the current pcase-lambda (and pcase-let) macro, the
> pcase.el code should be refined so as to emit a warning when it ends up
> ignoring a constant like `fullsweep_after' above.

Yes, I am having a lot of trouble understanding and using pcase-let*
except for trivial cases. I don't want the same thing to happen to
pcase-lambda.

>        Stefan

Thanks,
Leo