New assoc-let package

New assoc-let package

[Artur Malabarba]

Hi All,

As part of another project, which involves excessive handing of
alists, I wrote up a little macro which has turned out to be
stupendously useful. I'm just checking whether this functionality is
already offered somewhere, because if it isn't I'll make an Elpa
package for it.

Simply put, the macro takes an alist and a body, and makes the data of
the alist accessible by just writing the car of the desired cell
preceded by a dot.
For instance, the following:

  (assoc-let alist
    (if (and .title .body)
        .body
      .site))

expands to

  (let ((.title (cdr (assoc 'title alist)))
        (.body (cdr (assoc 'body alist)))
        (.site (cdr (assoc 'site alist))))
    (if (and .title .body)
        .body
      .site))


Obviously, this only works for alist elements whose car are symbols,
and it shadows outside variables whose names start with a dot (which
I've never ever run into). Still, this has proven invaluable for
processing the output of `json-read'.

Cheers
Malabarba

Re: New assoc-let package

[Stefan Monnier]

>>>>> "Artur" == Artur Malabarba <bruce.connor.am@gmail.com> writes:

> Hi All,
> As part of another project, which involves excessive handing of
> alists, I wrote up a little macro which has turned out to be
> stupendously useful. I'm just checking whether this functionality is
> already offered somewhere, because if it isn't I'll make an Elpa
> package for it.

> Simply put, the macro takes an alist and a body, and makes the data of
> the alist accessible by just writing the car of the desired cell
> preceded by a dot.
> For instance, the following:

>   (assoc-let alist
>     (if (and .title .body)
>         .body
>       .site))

I don't know of any package that does something like that, no.
The way I'd have done it is

    (cl-macrolet (((a field) `(cdr (assq ,field alist))))
      (if (and (a title) (a body))
          (a body)
        (a site)))


-- Stefan

Re: New assoc-let package

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 296 bytes --]

> The way I'd have done it is
>
>     (cl-macrolet (((a field) `(cdr (assq ,field alist))))
>       (if (and (a title) (a body))
>           (a body)
>         (a site)))
>

Indeed, I was doing almost the same thing initially (just using cl-flet
instead), but eventually even that grew tiresome.

[-- Attachment #2: Type: text/html, Size: 407 bytes --]

Re: New assoc-let package

[Leo Liu]

On 2014-12-05 00:36 +0000, Artur Malabarba wrote:
> Indeed, I was doing almost the same thing initially (just using cl-flet
> instead), but eventually even that grew tiresome.

Or do something like this:

(pcase (alist-get-keys alist key1 key2 key3)
  (`(,val1 ,val2 ,val3) body))

Leo

Re: New assoc-let package

[Ted Zlatanov]

On Fri, 05 Dec 2014 10:49:42 +0800 Leo Liu <sdl.web@gmail.com> wrote: 

LL> On 2014-12-05 00:36 +0000, Artur Malabarba wrote:
>> Indeed, I was doing almost the same thing initially (just using cl-flet
>> instead), but eventually even that grew tiresome.

LL> Or do something like this:

LL> (pcase (alist-get-keys alist key1 key2 key3)
LL>   (`(,val1 ,val2 ,val3) body))

That's neat but you need to select the keys in advance.  I like the
automagic of Artur's approach better, as long as the alist is small.

Ted

Re: New assoc-let package

[Ted Zlatanov]

On Wed, 3 Dec 2014 23:40:14 +0000 Artur Malabarba <bruce.connor.am@gmail.com> wrote: 

AM> Simply put, the macro takes an alist and a body, and makes the data of
AM> the alist accessible by just writing the car of the desired cell
AM> preceded by a dot.
AM> For instance, the following:

AM>   (assoc-let alist
AM>     (if (and .title .body)
AM>         .body
AM>       .site))

AM> expands to

AM>   (let ((.title (cdr (assoc 'title alist)))
AM>         (.body (cdr (assoc 'body alist)))
AM>         (.site (cdr (assoc 'site alist))))
AM>     (if (and .title .body)
AM>         .body
AM>       .site))

I really, really like it.  Like a `destructuring-bind' for alists.

Should it maybe use `lexical-let'?

I hope it can go into the core so it's available by default.

Ted

Re: New assoc-let package

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 348 bytes --]

>
> I really, really like it.  Like a `destructuring-bind' for alists.
>
> Should it maybe use `lexical-let'?

Maybe. Do you foresee it behaving unexpectedly in a file with dynamic
scope?

>
> I hope it can go into the core so it's available by default.
>

On the other hand, making it a package makes it a reliable dependency
available since 24.1

[-- Attachment #2: Type: text/html, Size: 483 bytes --]

Re: New assoc-let package

[Ted Zlatanov]

On Fri, 5 Dec 2014 00:33:44 +0000 Artur Malabarba <bruce.connor.am@gmail.com> wrote: 

>> I really, really like it.  Like a `destructuring-bind' for alists.
>> 
>> Should it maybe use `lexical-let'?

AM> Maybe. Do you foresee it behaving unexpectedly in a file with dynamic
AM> scope?

If you want to support older Emacsen, it's probably better. But it's up
to you, and I don't know exactly what your code does (I was going from
the macro expansion you posted).

>> I hope it can go into the core so it's available by default.

AM> On the other hand, making it a package makes it a reliable dependency
AM> available since 24.1

To me, a package seems overkill for a single useful macro, but I haven't
seen the source so perhaps there's more to it. There was no URL in your
post and I don't see an assoc-let package in any of the ELPA repos I
know.

Anyhow, it's your code, please publish it however you wish.

Ted

Re: New assoc-let package

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 1087 bytes --]

On 5 Dec 2014 00:45, "Ted Zlatanov" <tzz@lifelogs.com> wrote:
> >> Should it maybe use `lexical-let'?
>
> AM> Maybe. Do you foresee it behaving unexpectedly in a file with dynamic
> AM> scope?
>
> If you want to support older Emacsen, it's probably better. But it's up
> to you, and I don't know exactly what your code does.

> >> I hope it can go into the core so it's available by default.
>
> AM> On the other hand, making it a package makes it a reliable dependency
> AM> available since 24.1
>
> To me, a package seems overkill for a single useful macro, but I haven't
> seen the source so perhaps there's more to it. There was no URL in your
> post and I don't see an assoc-let package in any of the ELPA repos I
> know.

Yes, when I sent that email I hadn't yet factored it out from the other
project where it was born.

I've attached the file now. There isn't much more to it, it's really quite
simple.


> Anyhow, it's your code, please publish it however you wish.

Of course, but all feedback is welcome.

I'll be pushing this once I've written a test or two for it.


Cheers

[-- Attachment #2: Type: text/html, Size: 1485 bytes --]

Re: New assoc-let package

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 1317 bytes --]

And of course I forgot to attach.
Artur Malabarba

School of Physics,
University of Bristol, UK
(+44) 07450 374440


2014-12-05 20:27 GMT+00:00 Artur Malabarba <arturmalabarba@gmail.com>:
> On 5 Dec 2014 00:45, "Ted Zlatanov" <tzz@lifelogs.com> wrote:
>> >> Should it maybe use `lexical-let'?
>>
>> AM> Maybe. Do you foresee it behaving unexpectedly in a file with dynamic
>> AM> scope?
>>
>> If you want to support older Emacsen, it's probably better. But it's up
>> to you, and I don't know exactly what your code does.
>
>> >> I hope it can go into the core so it's available by default.
>>
>> AM> On the other hand, making it a package makes it a reliable dependency
>> AM> available since 24.1
>>
>> To me, a package seems overkill for a single useful macro, but I haven't
>> seen the source so perhaps there's more to it. There was no URL in your
>> post and I don't see an assoc-let package in any of the ELPA repos I
>> know.
>
> Yes, when I sent that email I hadn't yet factored it out from the other
> project where it was born.
>
> I've attached the file now. There isn't much more to it, it's really quite
> simple.
>
>
>> Anyhow, it's your code, please publish it however you wish.
>
> Of course, but all feedback is welcome.
>
> I'll be pushing this once I've written a test or two for it.
>
>
> Cheers

[-- Attachment #2: assoc-let.el --]
[-- Type: text/x-emacs-lisp, Size: 3375 bytes --]

;;; assoc-let.el --- Easily let-bind values of an alist by their names.

;; Copyright (C) 2014 Free Software Foundation, Inc.

;; Author: Artur Malabarba <bruce.connor.am@gmail.com>
;; Maintainer: Artur Malabarba <bruce.connor.am@gmail.com>
;; URL: http://github.com/Bruce-Connor/assoc-let
;; Version: 0.1
;; Keywords: extensions lisp
;; Prefix: assoc-let
;; Separator: -

;;; Commentary:
;;
;; This package offers a single macro, `assoc-let'. This macro takes a
;; first argument (whose value must be an alist) and a body.
;; 
;; The macro expands to a let form containing body, where each dotted
;; symbol inside body is let-bound to their cdrs in the alist.  Dotted
;; symbol is any symbol starting with a `.'.  Only those present in
;; the body are let-bound and this search is done at compile time.
;; 
;; For instance, the following code
;; 
;;   (assoc-let alist
;;     (if (and .title .body) 
;;         .body
;;       .site))
;; 
;; expands to
;; 
;;   (let ((.title (cdr (assoc 'title alist)))
;;         (.body (cdr (assoc 'body alist)))
;;         (.site (cdr (assoc 'site alist))))
;;     (if (and .title .body)
;;         .body
;;       .site))

;;; License:
;;
;; This file is part of GNU Emacs.
;;
;; GNU Emacs is free software: you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.
;;
;; GNU Emacs is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.
;;
;; You should have received a copy of the GNU General Public License
;; along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.

;;; News:
;;; Code:
\f

(defun assoc-let--deep-dot-search (data)
  "Return alist of symbols inside DATA which start with a `.'.
Perform a deep search and return an alist where each car is the
symbol, and each cdr is the same symbol without the `.'."
  (cond
   ((symbolp data)
    (let ((name (symbol-name data)))
      (when (string-match "\\`\\." name)
        ;; Return the cons cell inside a list, so it can be appended
        ;; with other results in the clause below.
        (list (cons data (intern (replace-match "" nil nil name)))))))
   ((not (listp data)) nil)
   (t (apply #'append
        (remove nil (mapcar #'assoc-let--deep-dot-search data))))))

;;;###autoload
(defmacro assoc-let (alist &rest body)
  "Let-bind dotted symbols to their cdrs in ALIST and execute BODY.
Dotted symbol is any symbol starting with a `.'.  Only those
present in BODY are let-bound and this search is done at compile
time.

For instance, the following code

  (assoc-let alist
    (if (and .title .body) 
        .body
      .site))

expands to

  (let ((.title (cdr (assoc 'title alist)))
        (.body (cdr (assoc 'body alist)))
        (.site (cdr (assoc 'site alist))))
    (if (and .title .body)
        .body
      .site))"
  (declare (indent 1) (debug t))
  `(let ,(mapcar (lambda (x) `(,(car x) (cdr (assoc ',(cdr x) ,alist))))
                 (delete-dups (assoc-let--deep-dot-search body)))
     ,@body))

(provide 'assoc-let)
;;; assoc-let.el ends here


;; Local Variables:
;; sentence-end-double-space: t
;; End:

Re: New assoc-let package

[Christopher Schmidt]

Artur Malabarba <arturmalabarba@gmail.com> writes:
> ;;;###autoload
> (defmacro assoc-let (alist &rest body)
>   "Let-bind dotted symbols to their cdrs in ALIST and execute BODY.
> Dotted symbol is any symbol starting with a `.'.  Only those
> present in BODY are let-bound and this search is done at compile
> time.
>
> For instance, the following code
>
>   (assoc-let alist
>     (if (and .title .body)
>         .body
>       .site))
>
> expands to
>
>   (let ((.title (cdr (assoc 'title alist)))
>         (.body (cdr (assoc 'body alist)))
>         (.site (cdr (assoc 'site alist))))
>     (if (and .title .body)
>         .body
>       .site))"
>   (declare (indent 1) (debug t))
>   `(let ,(mapcar (lambda (x) `(,(car x) (cdr (assoc ',(cdr x) ,alist))))
                                          (alist-get ',(cdr x) ,alist)
>                  (delete-dups (assoc-let--deep-dot-search body)))
                                                            (macroexpand-all body) ?
>      ,@body))

I do not think adding assoc-let (assq-let?) to the core is a good idea.
The inability to meaningfully nest different assoc-let forms makes the
macro inflexible.  It is probably a good idea to make the dotvars
generalized variables.

Re: New assoc-let package

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 418 bytes --]

On 6 Dec 2014 11:36, "Christopher Schmidt" <ch@ristopher.com> wrote:
>
> The inability to meaningfully nest different assoc-let forms makes the
> macro inflexible.

What would you consider meaningful nesting? Being able to access the
variables of the outer macro inside the inner macro?

> It is probably a good idea to make the dotvars
> generalized variables.
>

I'd really like that, but I'll have to look into it.

[-- Attachment #2: Type: text/html, Size: 608 bytes --]

Re: New assoc-let package

[Christopher Schmidt]

Artur Malabarba <bruce.connor.am@gmail.com> writes:
> On 6 Dec 2014 11:36, "Christopher Schmidt" <ch@ristopher.com> wrote:
>> The inability to meaningfully nest different assoc-let forms makes
>> the macro inflexible.
>
> What would you consider meaningful nesting? Being able to access the
> variables of the outer macro inside the inner macro?

Yeah, that is what I meant.  Maybe the macro can support optional args
that specify the keys to be used.

    (assoc-let .foo .bar alist1
      (assoc-let .rms .gpl alist2 ; foo and bar bound to alist1
        ...                       ; rms and gpl bound to alist2

Maybe the name alist-let is more appropriate than assoc-let or assq-let
as this facility is of the same kind as alist-get.

Re: New assoc-let package

[Ted Zlatanov]

On Sat,  6 Dec 2014 14:58:36 -0500 (EST) Christopher Schmidt <ch@ristopher.com> wrote: 

CS> Artur Malabarba <bruce.connor.am@gmail.com> writes:
>> On 6 Dec 2014 11:36, "Christopher Schmidt" <ch@ristopher.com> wrote:
>>> The inability to meaningfully nest different assoc-let forms makes
>>> the macro inflexible.
>> 
>> What would you consider meaningful nesting? Being able to access the
>> variables of the outer macro inside the inner macro?

CS> Yeah, that is what I meant.  Maybe the macro can support optional args
CS> that specify the keys to be used.

CS>     (assoc-let .foo .bar alist1
CS>       (assoc-let .rms .gpl alist2 ; foo and bar bound to alist1
CS>         ...                       ; rms and gpl bound to alist2

I think the CL package does this kind of magic using gensyms.  I
personally find it hard to examine in a stack trace, but really
convenient as a user.

CS> Maybe the name alist-let is more appropriate than assoc-let or assq-let
CS> as this facility is of the same kind as alist-get.

`let-assoc' so it starts with the functionality it provides, not with
the data format it uses?

Ted

Re: New assoc-let package

[Ted Zlatanov]

On Fri, 5 Dec 2014 20:27:17 +0000 Artur Malabarba <arturmalabarba@gmail.com> wrote: 

AM> I've attached the file now. There isn't much more to it, it's really quite
AM> simple.

Yes, it's small enough that I'd just put it in the Emacs core somewhere.

If you choose to offer it as a package too, I wonder if it could be a
built-in Emacs package. I don't know how that mechanism works but
`list-packages' will show some built-ins. Then you could have it both
ways.  Like I said, it's up to you.

Stefan, is there a guide on how built-in packages work or should we just
dig into the source?

Ted

Re: New assoc-let package

[Stefan Monnier]

> Yes, it's small enough that I'd just put it in the Emacs core somewhere.

subr-x.el would be the obvious choice if you want it "in the core".

> Stefan, is there a guide on how built-in packages work or should we just
> dig into the source?

IIRC you just need to put a "Package:" and a "Version:" header.


        Stefan

Re: New assoc-let package

[Ted Zlatanov]

On Fri, 05 Dec 2014 23:55:14 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> Yes, it's small enough that I'd just put it in the Emacs core somewhere.
SM> subr-x.el would be the obvious choice if you want it "in the core".

>> Stefan, is there a guide on how built-in packages work or should we just
>> dig into the source?

SM> IIRC you just need to put a "Package:" and a "Version:" header.

Thanks! Artur hasn't indicated if he wants to add it in the core as a
package (also released on the ELPAs) or just a macro or not at all.

I would change the package name to `let-assoc' so it starts with the
thing it resembles, but otherwise I still think it would be useful.

Artur, can you please decide either way? I think, given the namespace
discussion happening in parallel, you should release your code as it
stands and release a newer version when you figure out how to deal with
nesting (using namespaces, gensyms, whatever).

Thanks
Ted

Re: New assoc-let package

[Artur Malabarba]

Sorry I went awol, very long plane ride.

2014-12-08 10:56 GMT+00:00 Ted Zlatanov > Thanks! Artur hasn't
indicated if he wants to add it in the core as a
> package (also released on the ELPAs) or just a macro or not at all.

I gave this some thought, and I'd like to make it a core pacage also
on Elpa. The only reason I'm not a fan is of making it just a macro in
subr-x is that it wouldn't be available on older versions, and that I
essentially means I wouldn't use it myself.

Is it an option to offer `subr-x' as a GNU Elpa package? Or would that
pose a compatibility challenge given that the file doesn't have
package headers on 24.4?

>
> I would change the package name to `let-assoc' so it starts with the
> thing it resembles, but otherwise I still think it would be useful.

Thanks, I like that suggestion.

> Artur, can you please decide either way? I think, given the namespace
> discussion happening in parallel, you should release your code as it
> stands and release a newer version when you figure out how to deal with
> nesting (using namespaces, gensyms, whatever).

Yes, the nesting will be left for a next release.

Re: New assoc-let package

[Ted Zlatanov]

On Mon, 8 Dec 2014 12:11:03 +0000 Artur Malabarba <bruce.connor.am@gmail.com> wrote: 

AM> I gave this some thought, and I'd like to make it a core pacage also
AM> on Elpa. The only reason I'm not a fan is of making it just a macro in
AM> subr-x is that it wouldn't be available on older versions, and that I
AM> essentially means I wouldn't use it myself.

Go ahead and make a "let-assoc" package with the right headers. I'll add
it to the core (unless Stefan or someone else objects) and you can
independently add it to the GNU ELPA or wherever you want. It's a fairly
small package but maybe that's not a bad thing.

AM> Is it an option to offer `subr-x' as a GNU Elpa package? Or would that
AM> pose a compatibility challenge given that the file doesn't have
AM> package headers on 24.4?

I don't think that would work.  It's too tightly bound to Emacs itself.

Ted

Re: New assoc-let package

[Stefan Monnier]

> Is it an option to offer `subr-x' as a GNU Elpa package?

Not really, no.

But if all goes according to plan, Emacs-25 should be released by
bundling some GNU ELPA packages into it (Company-mode, hopefully, and
Org-mode as well (which should move out of emacs.git and into
elpa.git)).


        Stefan

Re: New assoc-let package

[Stefan Monnier]

> I would change the package name to `let-assoc' so it starts with the
> thing it resembles, but otherwise I still think it would be useful.

I don't see why "assoc" rather than "alist".


        Stefan

Re: New assoc-let package

[Ted Zlatanov]

On Mon, 08 Dec 2014 09:59:10 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> I would change the package name to `let-assoc' so it starts with the
>> thing it resembles, but otherwise I still think it would be useful.

SM> I don't see why "assoc" rather than "alist".

Works for me either way :)  I was just preserving Artur's original name
as much as possible, but yeah, `let-alist' would be more intuitive.

Ted

Re: New assoc-let package

[Stefan Monnier]

> I don't see why "assoc" rather than "alist".

Please scratch that, they both make about as much sense.
I prefer my bikeshed green with pink flowers, tho.


        Stefan

Re: New assoc-let package

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 361 bytes --]

On 8 Dec 2014 12:59, "Stefan Monnier" <monnier@iro.umontreal.ca> wrote:
>
> > I would change the package name to `let-assoc' so it starts with the
> > thing it resembles, but otherwise I still think it would be useful.
>
> I don't see why "assoc" rather than "alist".
>

TBH, I'm entirely neutral on this whole name thing. All options sound
equally fine to me.

[-- Attachment #2: Type: text/html, Size: 536 bytes --]

Re: New assoc-let package

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 69 bytes --]

Ok, I'll flip a coin for the name and send the file later today. :-)

[-- Attachment #2: Type: text/html, Size: 91 bytes --]

Re: New assoc-let package

[Stefan Monnier]

> Ok, I'll flip a coin for the name and send the file later today. :-)

Please use a good coin.  I prefer the big 5 swiss francs coins.


        Stefan

Re: New assoc-let package

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 133 bytes --]

And here's the file.
The best I could do was a 2 pounds coin. Hopefully the 10% size
reduction didn't influence the result too much.

[-- Attachment #2: let-alist.el --]
[-- Type: text/x-emacs-lisp, Size: 3322 bytes --]

;;; let-alist.el --- Easily let-bind values of an assoc-list by their names.

;; Copyright (C) 2014 Free Software Foundation, Inc.

;; Author: Artur Malabarba <bruce.connor.am@gmail.com>
;; Maintainer: Artur Malabarba <bruce.connor.am@gmail.com>
;; Version: 1.0
;; Keywords: extensions lisp
;; Prefix: let-alist
;; Separator: -

;;; Commentary:
;;
;; This package offers a single macro, `let-alist'.  This macro takes a
;; first argument (whose value must be an alist) and a body.
;;
;; The macro expands to a let form containing body, where each dotted
;; symbol inside body is let-bound to their cdrs in the alist.  Dotted
;; symbol is any symbol starting with a `.'.  Only those present in
;; the body are let-bound and this search is done at compile time.
;; 
;; For instance, the following code
;; 
;;   (let-alist alist
;;     (if (and .title .body)
;;         .body
;;       .site))
;; 
;; expands to
;; 
;;   (let ((.title (cdr (assq 'title alist)))
;;         (.body (cdr (assq 'body alist)))
;;         (.site (cdr (assq 'site alist))))
;;     (if (and .title .body)
;;         .body
;;       .site))

;;; License:
;;
;; This file is part of GNU Emacs.
;;
;; GNU Emacs is free software: you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.
;;
;; GNU Emacs is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.
;;
;; You should have received a copy of the GNU General Public License
;; along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.

;;; News:
;;; Code:
\f

(defun let-alist--deep-dot-search (data)
  "Return alist of symbols inside DATA which start with a `.'.
Perform a deep search and return an alist where each car is the
symbol, and each cdr is the same symbol without the `.'."
  (cond
   ((symbolp data)
    (let ((name (symbol-name data)))
      (when (string-match "\\`\\." name)
        ;; Return the cons cell inside a list, so it can be appended
        ;; with other results in the clause below.
        (list (cons data (intern (replace-match "" nil nil name)))))))
   ((not (listp data)) nil)
   (t (apply #'append
        (remove nil (mapcar #'let-alist--deep-dot-search data))))))

;;;###autoload
(defmacro let-alist (alist &rest body)
  "Let-bind dotted symbols to their cdrs in ALIST and execute BODY.
Dotted symbol is any symbol starting with a `.'.  Only those
present in BODY are let-bound and this search is done at compile
time.

For instance, the following code

  (let-alist alist
    (if (and .title .body)
        .body
      .site))

expands to

  (let ((.title (cdr (assq 'title alist)))
        (.body (cdr (assq 'body alist)))
        (.site (cdr (assq 'site alist))))
    (if (and .title .body)
        .body
      .site))"
  (declare (indent 1) (debug t))
  `(let ,(mapcar (lambda (x) `(,(car x) (cdr (assq ',(cdr x) ,alist))))
                 (delete-dups (let-alist--deep-dot-search body)))
     ,@body))

(provide 'let-alist)
;;; let-alist.el ends here


;; Local Variables:
;; sentence-end-double-space: t
;; End:

Re: New assoc-let package

[Stefan Monnier]

> The best I could do was a 2 pounds coin.

Then the result is not valid,


        Stefan

Re: New assoc-let package

[Ted Zlatanov]

On Fri, 05 Dec 2014 23:55:14 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> Yes, it's small enough that I'd just put it in the Emacs core somewhere.
SM> subr-x.el would be the obvious choice if you want it "in the core".

>> Stefan, is there a guide on how built-in packages work or should we just
>> dig into the source?

SM> IIRC you just need to put a "Package:" and a "Version:" header.

Hmm, I don't see that the Package header is necessary. At least
cfengine.el doesn't have it.  Am I missing something?

On Tue, 9 Dec 2014 03:37:45 +0000 Artur Malabarba <bruce.connor.am@gmail.com> wrote: 

AM> And here's the file.

I've pushed it to the branch tzz/let-alist-package for review.

Artur, can you check my minor changes?

Stefan, is this good enough or do you want me to add a Package header
too?

Thanks
Ted

Re: New assoc-let package

[Stefan Monnier]

> Hmm, I don't see that the Package header is necessary.  At least
> cfengine.el doesn't have it.  Am I missing something?

You're probably right.


        Stefan

Re: New assoc-let package

[Ted Zlatanov]

On Wed, 10 Dec 2014 10:43:23 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> Hmm, I don't see that the Package header is necessary.  At least
>> cfengine.el doesn't have it.  Am I missing something?

SM> You're probably right.

All right, when Artur gives the final OK, I'll merge to master. He's in
the ChangeLog already so his contributor papers are OK.

I was thinking of maybe putting this in a "subr" subdirectory for small
core packages. We can adjust it later if you want that.

Ted

Re: New assoc-let package

[Artur Malabarba]

2014-12-10 15:49 GMT+00:00 Ted Zlatanov <tzz@lifelogs.com>:
> On Wed, 10 Dec 2014 10:43:23 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
>>> Hmm, I don't see that the Package header is necessary.  At least
>>> cfengine.el doesn't have it.  Am I missing something?
>
> SM> You're probably right.
>
> All right, when Artur gives the final OK, I'll merge to master. He's in
> the ChangeLog already so his contributor papers are OK.

Thanks Ted, there's only one small thing I'd like to add at the end of
the header comments (quoted below).
I've added it as an ammend to your branch, and pushed it to the
malabarba/let-alist-package-rc3 branch.

;; Note that only one level is supported.  If you nest `let-alist'
;; invocations, the inner one can't access the variables of the outer
;; one.

If you're ok with that feel free to merge.

Re: New assoc-let package

[Ted Zlatanov]

On Wed, 10 Dec 2014 16:28:19 -0200 Artur Malabarba <bruce.connor.am@gmail.com> wrote: 

AM> 2014-12-10 15:49 GMT+00:00 Ted Zlatanov <tzz@lifelogs.com>:
>> On Wed, 10 Dec 2014 10:43:23 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> 
>>>> Hmm, I don't see that the Package header is necessary.  At least
>>>> cfengine.el doesn't have it.  Am I missing something?
>> 
SM> You're probably right.
>> 
>> All right, when Artur gives the final OK, I'll merge to master. He's in
>> the ChangeLog already so his contributor papers are OK.

AM> Thanks Ted, there's only one small thing I'd like to add at the end of
AM> the header comments (quoted below).
AM> I've added it as an ammend to your branch, and pushed it to the
AM> malabarba/let-alist-package-rc3 branch.

AM> ;; Note that only one level is supported.  If you nest `let-alist'
AM> ;; invocations, the inner one can't access the variables of the outer
AM> ;; one.

I added something similar but yours is better :)

;; Note that only one level is supported.  You can't nest `let-alist'
;; invocations safely.

AM> If you're ok with that feel free to merge.

Yup, except I cherry-picked to avoid the unnecessary merge message.
Feel free to delete your RC branch--I deleted mine.

Ted

Re: New assoc-let package

[Stefan Monnier]

> I was thinking of maybe putting this in a "subr" subdirectory for small

Don't.  Unless you already have about 20 packages to put in there.


        Stefan

Re: New assoc-let package

[Ted Zlatanov]

On Wed, 10 Dec 2014 14:09:58 -0500 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 

>> I was thinking of maybe putting this in a "subr" subdirectory for small
SM> Don't.  Unless you already have about 20 packages to put in there.

Damn, and I was going to push it tonight ;)  No problem, just thinking
out loud.

Ted