Re: Replace trivial pcase occurrences in the Emacs sources

[Andy Moreton]

On Wed 31 Oct 2018, Clément Pit-Claudel wrote:

> On 30/10/2018 20.08, Andy Moreton wrote:
>> On Tue 30 Oct 2018, Clément Pit-Claudel wrote:
>> 
>>> On 30/10/2018 14.14, Alan Mackenzie wrote:
>>>> Hello, Clément.
>>>
>>> Hey Alan :)
>>>
>>>> On Tue, Oct 30, 2018 at 11:05:55 -0400, Clément Pit-Claudel wrote:
>>>>> On 30/10/2018 10.16, Andy Moreton wrote:
>>>>>> How are users meant to write reliable code using such constructs ?
>>>>
>>>>> Ensure that the pattern actually matches :)
>>>>
>>>> You mean, unless you can be 100% sure that the pattern will match, you
>>>> mustn't use pcase-... constructs.  That sounds equivalent to saying you
>>>> shouldn't use these constructs at all.
>>>
>>> That's an odd conclusion.
>> 
>> It is a perfectly reasonable conclusion. 
>
> Why? A large number of ELisp functions don't say what they do if their
> argument isn't of the expected type, or doesn't have the expected structure.
> If you're not 100% sure that the argument has the right type, you shouldn't
> use them (instead, you should do an appropriate check first). This is not
> equivalent to saying that they shouldn't be used at all.
>
> I don't understand what's so special about pcase-*. Functions like lookup-key
> or define-key don't tell you what happens if you pass something else that a
> keymap; does that mean you should never use them? Same for a function like
> `c-common-init' in cc-mode (the doc doesn't tell you what happens if you pass
> a symbol that isn't a mode; AFAICT, if you do, you get an error but the
> current buffer is left in a broken state.

The difference is that the non-pcase constructs can document exactly
which types are acceptable as arguments. For the pcase macros, the
acceptable argument types are not fixed by the pcase macro, but depend
on the patterns used. That is harder to explain clearly, and harder for
the user to reason about correctness of the code that they write.

    AndyM