[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Code for cond*
From: |
JD Smith |
Subject: |
Re: Code for cond* |
Date: |
Wed, 24 Jan 2024 11:20:38 -0500 |
> On Jan 24, 2024, at 10:55 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
>> To explain this correctly, I’d need to understand where the mental
>> model breaks down. For example, I was surprised that this
>> forward/reverse symmetry was not maintained:
>>
>> (let ((list-var '(foo moo loo))
>> (other 'boo))
>> `(,@list-var . ,other)). ; -> (foo moo loo . boo)
>>
>> (pcase '(foo moo loo . boo)
>> (`(,@list-var . ,other)
>> (format "Got %S: %S" list-var other))). ; -> nil, expected “Got (foo moo
>> loo): boo"
>
> Note that
>
> (let ((list-var '(foo moo))
> (other '(loo . boo)))
> `(,@list-var . ,other))
>
> returns the same `(foo moo loo . boo)`, so there is not a unique way for
> a pattern like `(,@list-var . ,other) to match a given list.
> That's a large part of the reason why ,@ is not supported in Pcase's
> backquote patterns.
Not a unique way without a policy, but could it not take the largest possible
list at that position, ala regexp greedy matching?
Any other forward/reverse asymmetries you are aware of (other than the use of
meaningful sub-lists with symbols like pred/and/or/guard for pcase to
interpret)?
- Re: Code for cond*, (continued)
Re: Code for cond*, Richard Stallman, 2024/01/19
Re: Code for cond*, Stefan Monnier, 2024/01/23
- Re: Code for cond*, JD Smith, 2024/01/23
- Re: Code for cond*, Stefan Kangas, 2024/01/24
- Re: Code for cond*, JD Smith, 2024/01/24
- Re: Code for cond*, Stefan Monnier, 2024/01/24
- Re: Code for cond*, Stefan Monnier, 2024/01/24
- Re: Code for cond*,
JD Smith <=
- Re: Code for cond*, Stefan Monnier, 2024/01/24
- RE: [External] : Re: Code for cond*, Drew Adams, 2024/01/24
RE: [External] : Re: Code for cond*, Drew Adams, 2024/01/24
Re: Code for cond*, Madhu, 2024/01/25
Re: Code for cond*, Stefan Monnier, 2024/01/25
Re: Code for cond*, JD Smith, 2024/01/25
Re: Code for cond*, JD Smith, 2024/01/25
Re: Code for cond*, Alfred M. Szmidt, 2024/01/25
Re: Code for cond*, JD Smith, 2024/01/25
Re: Code for cond*, Stefan Monnier, 2024/01/25