Re: cond* vs pcase

[Alfred M. Szmidt]

   >    I am not sure if Alfred meant that in his first message, perhaps he 
did, but
   >    Drew seems to be more in line with that thinking. At least I understand 
him so.
   >
   > I'm not alluding to any specific design principle, the core issue at
   > hand is communicating with the person reading the code.

   Yes, that is how I understand you; but I'll answer same as to Drew; I don't
   agree that this is the best way of expressing the intention.

   Both pcase and cl-case in this particular simple context I have posted, 
express
   the intention equally well. [...]

We disagree to the point that there cannot be any agreement on the
topic, they do not express the same intent, just like a cond and
explicit (eql .. 'foo) do not express the same intent as using 'case';
they maybe do the same thing, but there is more about intent than
that.

As for tangents of optimizations, I'm not going to discuss them at
all.

   It is rather that you are aware of the details of cl-case and pcase
   and understand that the pcase is more powerful and can express more
   powerful constructs. However just that fact that it is more
   powerful, does not mandate use of "simpler" construct. As Adam
   illustrated, in this particular scenario, cond, cl-case and pcase
   expressed equally well the intention. The runtime cost is about the
   same too; so I don't think the implementation deatails should guide
   the decision. That seems to me like some sort of premature
   optimization, peep-hole optimization of intentions. I am not sure
   how to express myself here :).

   > The reason why we have ASSOC, ASSQ, ... are because they make it

   I am not sure if the reason is the clarity. I think we have, with all right,
   gone away from abbrevs and accronys such as "assq" or "memql" in function and
   variable names to more self-documenting code. Those functions are historical
   artefacts in my eyes.

These functions are integral parts of Lisp, to call them "historical
artefacts" is to not understand or care to understand the language.  

   > _clear_, _easy_ to understand code and to _use_.  A generic version is
   > not as easy to understand, or use.  Which is also a reason why
   > keywords are generally eskewed in Emacs Lisp.

   Is this not clear and understandable:

   (member elt list #'eql)
   (memeber elt list :test 'eql)

You missed a crucial part: to use.  Writing code is also important.
But no, I do not find those clear at all, you have more symbols to
read, specially when comparing against common types like integers, or
symbols.  You have the question of _why_ did the writer use that exact
form instead of already, well known, well documented, functions like
memql.  So under no cirucmstance does the above mean clear or
understandable, rather it raises more questions.

   Can we be more explicit in communication the intention which test funciton to
   use, if communicating exactly that intention is really important.

   Approoos nameing and historical artefacts, I read once an interview with Ken
   Thompson; I don't remember on which site, so I don't have the link, but they
   were asking him a bit about Unix design and a bit about C language amongst 
other
   things. On the question if he regret anything abotu Unix design, he said, if 
he
   regret he used "creat" instead of "create" as the name for the syscall.

I fail to see the point? Would you prefer mem-eql / member-eqal over
memql? They would do the same thing, which isn't the case comparing
pcase to case, cond to cond*, ...