RE: [External] : Re: cond* vs pcase

[Drew Adams <drew.adams@oracle.com>]

> [`equal'] is not really slower than using `eq'...

With this I agree completely.  `equal' just calls
`eq' first thing, whenever it can (and I imagine
compiling even takes that out of the equation
often).

That said, _in such cases_ telegraphing the fact
that the Lisp objects can and should be compared
with `eq' _helps human readers_.

With a slight stretch of language, this can fall
under the heading of helping readers by expressing
"intent".

> 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.  It's not about performance.

> 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's not "inherently wrong", if you're measuring
"wrong" by performance - or perhaps even by some
other criteria.

> It might be a personal preference, but nothing
> we could derive a general rule from -- which is fine.

It is indeed a style question.  But it doesn't
follow that stylistic guidelines don't, or can't,
or shouldn't exist.

The existing, documented Elisp guidelines don't
cover this.  Nor do they cover other conventions
such as using `when'/`unless' to telegraph that
the returned value isn't important as such.

They could, but they don't.  Such conventions
for conditionals do exist, and they're even
mentioned in CLTL2, IIRC (though CLTL2 doesn't
impose any style guidelines).

So yes, it's a personal stylistic preference.
Nevertheless, it doesn't hurt to discuss the
reasons for such a style - or for other styles.

Have we seen (here, now) any _reasons_ in favor
of always using `pcase' when something else
might do the job more simply?  Have we seen an
argument an argument in _favor_ of "using more
abstract"?

I can think of a couple, but they don't convince
me in light of the "communicate intent" argument:

1. One can maybe save some time or effort by
   learning only one construct (`pcase').  One
   size fits all has a certain economy to it.

2. With `pcase', later updates might sometimes
   not require as much editing.

I've never been an adoptee of the second.  I
prefer to have the code always express better
the intent, even if that means I need to edit
it more later, when things change slightly.
This can easily be the case with conventions
about when to use `if', `and', `when', etc.,
for example.

A lot is in the eye of the beholder - the
expected readers of the code.  Higher-order
functions such as `reduce' are elegant, and
their use can be succinct, for example.
(Elisp isn't a great fit for them, however.)
But a reader needs to have been introduced
to the genre.

YMMV.  Different strokes for different folks.
More and less abstraction can each have their
advantages, even for human readers (not to
mention performance).