Stefan Monnier <
monnier@iro.umontreal.ca> schrieb am Mi., 8. Apr. 2015 um 04:15 Uhr:
> After the recent rewrite, pcase-lambda is broken. For example, eval the
> following to get 46422 instead of the correct value 65535.
> (cl-some (pcase-lambda (`[fullsweep_after ,v]) v)
> '([min_bin_vheap_size 46422]
> [min_heap_size 233]
> [fullsweep_after 65535]
> [minor_gcs 40]))
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 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)))
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.
Why not raise an error instead if there is no match (or even if any quoted or self-quoting expressions are used at all)? The current behavior is quite confusing, and warnings tend to be ignored.
Given that pcase-let, pcase-lambda and pcase-dolist don't do any case-by-case analysis, maybe they should even be renamed and moved out of pcase.el.