emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cond* vs pcase


From: Thierry Volpiatto
Subject: Re: cond* vs pcase
Date: Tue, 06 Feb 2024 17:50:01 +0000

Philip Kaludercic <philipk@posteo.net> writes:

> "Alfred M. Szmidt" <ams@gnu.org> writes:
>
>>    "Alfred M. Szmidt" <ams@gnu.org> writes:
>>
>>    >    I use pcase often; but I use it just as a better cond. For example I 
>> find this
>>    >    handy:
>>    >
>>    >    (defvar foo nil) <-- foo is some symbol
>>    >
>>    >    (pcase foo
>>    >      ('bar (do-some-bar-stuff))
>>    >      ('baz (do-some-baz-fluff)))
>>    >
>>    > cl-case seems more appropriate here (wish cl-case was just case ...)
>>
>>    Why more appropriate?
>>
>> 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.
>
>>    I always think of pcase as Elisp's case.  In
>>    addition, pcase avoids the danger of naively writing 
>>
>>       (cl-case foo
>>      ('bar (do-some-bar-stuff))
>>      ('baz (do-some-baz-fluff)))
>>
>>    and then getting surprised when foo evaluates to `quote'.
>>
>> Suprises will happy, you will get suprises with pcase and cond* too --
>> I find it suprising that to match over symbols requires pattern
>> matching.  One might also question why you (well, no you specifically)
>> are comparing against (quote bar) etc?  That is a suprise in it self...
>
> I don't understand your point here.  If one expects the cases to be
> evaluated, then quoting makes sense if you want to match a symbol.  It
> is not true, but common enough that the byte compiler emits a warning.
>
>>    >    or this:
>>    >
>>    >    (setq foo "some-string")
>>    >
>>    >    (pcase foo
>>    >      ("foo" (do-foo-case))
>>    >      ("bar" (do-bar-case)))
>>    >
>>    > Same here, with (intern foo) ...
>>
>>    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...

-- 
Thierry



reply via email to

[Prev in Thread] Current Thread [Next in Thread]