Re: The poor state of documentation of pcase like things.

[Michael Heerdegen]

Lars Magne Ingebrigtsen <address@hidden> writes:

> Well, I'd say that pcase is kinda awkward because you can't tell by
> skimming whether it's complex or not (which is something it shares with
> cond, in a way).  Take for instance the following I was reading in
> url-http (simplified and way shortened):
>
>              (pcase status-symbol
>                (`unauthorized                   ; 401
>                 (url-http-handle-authentication nil))
>                (`payment-required              ; 402
>                 (url-mark-buffer-as-dead buffer)
>                 (error "Somebody wants you to give them money"))
>                (`forbidden                      ; 403
>                 t)
>                (`not-found                      ; 404
>                 t)
>                (`method-not-allowed             ; 405
>                 t)
>                ...)
>
> The only way you'll know whether `status-symbol' is really a symbol, and
> all the cases are really symbols, is by reading the entire thing.  The
> 44th case could have been (_ foo bar zot), for instance.

That code indeed looks weird.  But you can also write similarly weird
code with `cond'.

> I kinda liked pcase at first, but the more I see of the pcase language,
> the more sceptical I get.  I'm beginning to wonder whether the whole
> thing is a misfeature that should be replaced with several separate
> operators.

The concept (one can combine different types of things and tests -
destructuring, predicate testing, matching against constants etc.) has
it's pros and cons.  In cases where one single tool doesn't fit, it is a
very good thing when the code doesn't need to nest different types of
tools, and the layout can concentrate on the different cases.


Michael.