[Top][All Lists]

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

Re: [Emacs-diffs] master 387e1e1: New version of `seq-let' based on a pc

From: Nicolas Petton
Subject: Re: [Emacs-diffs] master 387e1e1: New version of `seq-let' based on a pcase pattern
Date: Mon, 11 May 2015 23:13:14 +0200

Stefan Monnier writes:

>> Yes.  My idea of it was that you bind a sequence like the following:
>>     (seq [a b [c d]])
> I was thinking of (seq a b (seq c d)).
> You could add support for (seq a b [c d]), if you want since that
> currently wouldn't collide with any pcase pattern, tho I'm not sure it's
> worth the added complexity for the user.
>> But then how can I have `seq-let' work the way it did until now? For
>> instance:
>>     (seq-let [a [b [c]]] my-vector
>>       ...)
> You expand [a [b [c]]] to (seq a (seq b (seq c))) before passing it to
> pcase-let.
>>>> +           (push `(app (seq--reverse-args #'seq--nested-elt
>>>> +                                          (reverse (cons ,index 
>>>> ',nested-indexes)))
>>>> +                       ,name)
>>> This reverse plus seq--reverse-args business seems
>>> hideously inefficient.  Why do you need that?
>> because of the way the `app' pattern works.  Or maybe I'm missing
>> something?
> Why wouldn't
>    `(app (seq--nested-elt ',(reverse (cons index nested-indexes))) ,name)
> work as well?  Or, once you get rid of the nested case,
>    `(app (seq-elt ,index) ,name)

I understand what you meant now. It indeed makes sense, and the pcase
pattern would be much more consistent. I'll push another commit.


> -- Stefan

Nicolas Petton

Attachment: signature.asc
Description: PGP signature

reply via email to

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