Re: cond* vs pcase

[Philip Kaludercic <philipk@posteo.net>]

"Alfred M. Szmidt" <ams@gnu.org> writes:

>    >    > Because your not doing pattern matching, you're comparing against a
>    >    > set of strings/symbols/numbers/....
>    >
>    >    Simply because pattern matching is a more powerful generalisation,
>    >    capable of expressing case-distinction; in the end it compiles down to
>    >    almost the same code anyway.
>    >
>    > Are you suggesting that COND/CASE/... and other "trivial" matching
>    > constructs should be replaced with PCASE/COND*?
>
>    No, just that using pcase in these cases isn't wrong.
>
> Then we disagree on a fundamental level.  This is just like like using
> EQUAL when comparing stricly strings is not the right tool for the
> job.

"Alfred M. Szmidt" <ams@gnu.org> writes:

>    Also interning strings just for the purpose of comparing them with eq or
>    eql is questionable...
>
> So is pattern matching over characters, numbers, and other simple
> types... 

In both cases here I think that there is a fundamental distinction
between functionality that is generic at compile-time and at run-time.
While `equal' vs `eq' is not pretty, the main issue for me here is that
you might accidentally compare and equate two string or lists that are
not the same object, which you sometimes don't want to do.  Otherwise it
is not really slower than using `eq', if that is what concerns you:

--8<---------------cut here---------------start------------->8---
(benchmark-run 10000000
  (eq 'foo 'bar))
;; (2.589085844 0 0.0)

(benchmark-run 10000000
  (equal 'foo 'bar))
;; (2.611292045 0 0.0)
--8<---------------cut here---------------end--------------->8---

The pattern matching code is all generated at compile-time, and even
uses the `eq' to compare symbols, instead of the less specific `eql'
(!).

Yes, this might be a fundamental disagreement, but I still don't think
that using more abstract means to solve a problem is inherently wrong.
It might be a personal preference, but nothing we could derive a general
rule from -- which is fine.