[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
- Re: [External] : Re: cond* vs pcase, (continued)
- Re: [External] : Re: cond* vs pcase, Stefan Monnier, 2024/02/12
- RE: [External] : Re: cond* vs pcase, Drew Adams, 2024/02/07
- Re: cond* vs pcase, Yuri Khan, 2024/02/07
- Re: cond* vs pcase, Arthur Miller, 2024/02/07
- Re: cond* vs pcase, Alfred M. Szmidt, 2024/02/07
- Re: cond* vs pcase, Arthur Miller, 2024/02/08
- Re: cond* vs pcase, Alfred M. Szmidt, 2024/02/07
- Re: cond* vs pcase, Arthur Miller, 2024/02/08
- RE: [External] : Re: cond* vs pcase, Drew Adams, 2024/02/06
- Re: [External] : Re: cond* vs pcase, Alfred M. Szmidt, 2024/02/06
- Re: cond* vs pcase,
Thierry Volpiatto <=
- Re: cond* vs pcase, Alfred M. Szmidt, 2024/02/06
- Re: cond* vs pcase, Barry Fishman, 2024/02/07
- RE: [External] : Re: cond* vs pcase, Drew Adams, 2024/02/07