Re: cond* vs pcase

[Barry Fishman]

On 2024-02-06 17:50:01 GMT, Thierry Volpiatto wrote:
> Philip Kaludercic <philipk@posteo.net> writes:
>> "Alfred M. Szmidt" <ams@gnu.org> writes:
>>>    "Alfred M. Szmidt" <ams@gnu.org> writes:
>>>    Being able to do equal instead of eql is also something that speaks in
>>>    favour of pcase...
>>>
>>> It speaks more in favor of having CASE where you can change the
>>> comparison operator or a CASE-STRING or similar, not something much
>>> more generic pcase (or even cond*!) -- i.e. why use pcase/cond* when
>>> you're not using any of the features that are the main point of those
>>> two macros.
>>
>> I am sorry, but I don't follow your point here either.  Is the general
>> claim, that one should only use whatever exactly and at most satisfies
>> the needs at hand?
>
> Also interning strings just for the purpose of comparing them with eq or
> eql is questionable...

If I remember right, in Common Lisp long case statements could be optimized
by the compiler to do a hash lookup in a table generated at compile
time.  The case form made it easy for the macro/compiler to figure this
out, and compilers were not as good as they are now.

Incidentally in Haskell, case is quite a different operation.  There 
the types are declared and know by the compiler, so it more a matter of
deconstructing a well defined type and possibly then checking the values to
meet some requirement.  This is far simpler for Haskell programmers to
recognize than the more complex situation that pcase/cond* are trying
to solve.

What bothers me the most about it is that rather the breaking these
problems into simpler operations and providing a means of composing them
to handle more complex situation, the pcase/cond*/loop constructs mix
them all in to a single form.

This is defended by saying that it helps move some of the complexity
from the user to the macro processor.  But like the current generation
of 'generative AI' solutions to problems, it seems to hide the
complexity in a way that subtle errors get hard to discover.  New coders
end up spending their time copying code fragments rather than
understanding what is going on.

-- 
Barry Fishman