Re: pcase vs. case (where it could also be used) [Was: Re: Replace trivial pcase occurrences in the Emacs sources]

["Garreau\, Alexandre" <galex-713@galex-713.eu>]

On 2018-10-23 at 16:19, Stefan Monnier wrote:
>> To push the reasoning on an extreme:
>
> Given Turing-equivalence, I don't think pushing the reasoning to the
> extreme will be a good guide.

Why?  We’re talking about what’s standard or not (so what need to be
redefined or not), what is (to be) popularized, common, etc. or not:
“if”, simple lambda, etc. exist in ML, but according “good ML style” are
(almost) never used, and pattern-matching forms is prefered (even when
there’s no destructuring).  The question is: do we want the same for
emacs-lisp?  I’m not personally fond enough of pattern-matching.  That
recalls me the kind of falsely consensual trends that created Rust.

pattern-matching is more intuitive, familiar and straightforward to read
to the unused user, but it is more complex (including but not limited to
of implementation), and I believe its familiarity is subjective or at
least deeply specific to the human cognition, not as systematically
particularly interesting on a logical or mathematical level.  As forms
such as case/switch/etc. are simpler, with some habit you can get
quickly get as much used to it as to pattern-matching, just like sexps:
more simple, less familiar, but then not long to get used to it.

Imho cases where simple `case' become unreadable and pcase becomes
necessary are symptoms of trying to implement something too complex at
once, that could be either breaked down into simpler and more meaningful
parts, or themselves symptoms of a complex spec or interface (where
pcase would then become a necessary evil, but it should be there to
indicate it as such).  But that might exit the subject scope.

>>> - once you learn it, you can use it elsewhere, e.g. pcase-let,
>>>   pcase-dolist, ...
>>
>> Could have been the same for cl-destructuring-bind.
>
> Except cl-destructuring-bind only covers (a subset of) pcase-let.
> It could cover pcase-let as well pcase-dolist, but not `pcase` itself.
> [ And even then, it would be less flexible than pcase-let because the
>   syntax of cl-destructuring-bind's patterns doesn't leave much space
>   for extensions.  ]

pcase is about pattern matching, that implies conditions, or at least
recognition or tests, pcase-let only does destructuring afaik, so
shouldn’t cl-destructuring-bind be improved instead, and all the pcase-*
functions actually only doing destructuring be based on it?

>> For instance, I personally have my own case* implementation for using
>> other test-fn than eql (such as equal,
>
> That highlights the problem that cl-case doesn't work with strings,
> forcing users like you to write their own alternative.

Ahh, that’s what you meant by “doesn’t work”.  Well, eq can still be
useful, for strings, I believe, otherwise eq wouldn’t exist and we would
only have equal (though this is what pcase does), so I wouldn’t call
that “doesn’t work”.  But a * version that takes a testfn as argument
can improve expressivity I believe (what if you want to compare, dunno,
hashes?)

>> the only possible one for pcase, and I don’t even hope making my own
>> version for eq/eql/etc.).
>
> Could you show me a pcase pattern where pcase's choice of equality
> is problematic?
> [ FWIW, there's only one case to comes to my mind.  ]

Now I know about the (equal ) pattern form, I guess a (eq ) wouldn’t be
that difficult to add, and as one of these would be mandatory to specify
non-constant (hence possibly same) strings (though maybe there’s a way
to trigger arbitrary computation from inside the pattern before another
get tried), it stays under control, so I don’t have any (case) anymore.