Anaphoric macros: increase visibility

Anaphoric macros: increase visibility

[Tino Calancha]

Hi,

I think anaphoric macros are a nice idiom; occasionally
they allow to write very concise and clear expressions.

AFAICS, in the Emacs tree they are just introduced
in ibuf-macs.el (`ibuffer-aif', `ibuffer-awhen').

To use these macros in Emacs code we must:
1) Define them again (code duplication).
2) Or require ibuf-macs, which it sounds not conventional.

It might have sense to move these general purpose macros
into a more visible location (subr.el or subr-x.el).

We might add other useful macros as well, e.g., awhile.

What do you think?

Tino

Re: Anaphoric macros: increase visibility

[Michael Heerdegen]

Tino Calancha <tino.calancha@gmail.com> writes:

> Hi,
>
> I think anaphoric macros are a nice idiom; occasionally
> they allow to write very concise and clear expressions.
>
> AFAICS, in the Emacs tree they are just introduced in ibuf-macs.el
> (`ibuffer-aif', `ibuffer-awhen').

We also already have `if-let' and `when-let' in "subr-x".  They are like
`aif' and `awhen' but you specify "it" explicitly.


Michael.

Re: Anaphoric macros: increase visibility

[Rolf Ade]

Michael Heerdegen <michael_heerdegen@web.de> writes:
> We also already have `if-let' and `when-let' in "subr-x".  They are like
> `aif' and `awhen' but you specify "it" explicitly.

Since you mention them ... I probably miss something obvious but from
looking at the documentation of if-let

    if-let is a Lisp macro in ‘subr-x.el’.

    (if-let BINDINGS THEN &rest ELSE)

    Process BINDINGS and if all values are non-nil eval THEN, else ELSE.
    Argument BINDINGS is a list of tuples whose car is a symbol to be
    bound and (optionally) used in THEN, and its cadr is a sexp to be
    evalled to set symbol’s value.  In the special case you only want
    to bind a single value, BINDINGS can just be a plain tuple.

and of if-when

    when-let is a Lisp macro in ‘subr-x.el’.

    (when-let BINDINGS &rest BODY)

    Process BINDINGS and if all values are non-nil eval BODY.
    Argument BINDINGS is a list of tuples whose car is a symbol to be
    bound and (optionally) used in BODY, and its cadr is a sexp to be
    evalled to set symbol’s value.  In the special case you only want
    to bind a single value, BINDINGS can just be a plain tuple.

I don't get, why there is a need for if-when?

Re: Anaphoric macros: increase visibility

[Rolf Ade]

Rolf Ade <rolf@pointsman.de> writes:
> I don't get, why there is a need for if-when?

... for when-let, of course ...

Re: Anaphoric macros: increase visibility

[Noam Postavsky]

On Fri, Jan 13, 2017 at 9:30 PM, Rolf Ade <rolf@pointsman.de> wrote:
>
> Michael Heerdegen <michael_heerdegen@web.de> writes:
>> We also already have `if-let' and `when-let' in "subr-x".  They are like
>> `aif' and `awhen' but you specify "it" explicitly.
>
> Since you mention them ... I probably miss something obvious but from
> looking at the documentation of if-let
>
>     (if-let BINDINGS THEN &rest ELSE)
>
> and of when-let
>
>     (when-let BINDINGS &rest BODY)
>
> I don't get, why there is a need for when-let?
>

Just like there is both `if' and `when', it's useful to have both
`if-let' and `when-let'.

Re: Anaphoric macros: increase visibility

[Richard Copley]

On 14 January 2017 at 03:03, Noam Postavsky
<npostavs@users.sourceforge.net> wrote:
> On Fri, Jan 13, 2017 at 9:30 PM, Rolf Ade <rolf@pointsman.de> wrote:
>>
>> Michael Heerdegen <michael_heerdegen@web.de> writes:
>>> We also already have `if-let' and `when-let' in "subr-x".  They are like
>>> `aif' and `awhen' but you specify "it" explicitly.
>>
>> Since you mention them ... I probably miss something obvious but from
>> looking at the documentation of if-let
>>
>>     (if-let BINDINGS THEN &rest ELSE)
>>
>> and of when-let
>>
>>     (when-let BINDINGS &rest BODY)
>>
>> I don't get, why there is a need for when-let?
>>
>
> Just like there is both `if' and `when', it's useful to have both
> `if-let' and `when-let'.
>

Rolf, `when' and `when-let' are macros that expand to the corresponding
`if' form without an ELSE, so strictly the `when' forms are redundant,
as you suggest. But they make the code easier and quicker to read
(and feel a little more natural to write), because you know the ELSE
is null without having to think about it. Finding the ELSE (if any) of
an `if' form can be quite a pain. The unusual indentation of the THEN
clause exists for the same reason, but it's a bit ugly, which is a
second (maybe less important) motivation for `when'.

Re: Anaphoric macros: increase visibility

[Tino Calancha]

On Fri, 13 Jan 2017, Michael Heerdegen wrote:

> Tino Calancha <tino.calancha@gmail.com> writes:
>
>> Hi,
>>
>> I think anaphoric macros are a nice idiom; occasionally
>> they allow to write very concise and clear expressions.
>>
>> AFAICS, in the Emacs tree they are just introduced in ibuf-macs.el
>> (`ibuffer-aif', `ibuffer-awhen').
>
> We also already have `if-let' and `when-let' in "subr-x".  They are like
> `aif' and `awhen' but you specify "it" explicitly.
They looks also fun.  Thanks.
I wonder if it has sense to increase that family with a while-let
(maybe others in case they are useful).

From 60f26b512b191add12a0c91dc4d7ff95aba080d9 Mon Sep 17 00:00:00 2001
From: Tino Calancha <tino.calancha@gmail.com>
Date: Sat, 14 Jan 2017 14:25:42 +0900
Subject: [PATCH] * lisp/emacs-lisp/subr-x.el (while-let): New macro.

---
  lisp/emacs-lisp/subr-x.el | 9 +++++++++
  1 file changed, 9 insertions(+)

diff --git a/lisp/emacs-lisp/subr-x.el b/lisp/emacs-lisp/subr-x.el
index 7736225b5f..5e7fdfaa09 100644
--- a/lisp/emacs-lisp/subr-x.el
+++ b/lisp/emacs-lisp/subr-x.el
@@ -141,6 +141,15 @@ when-let
    (declare (indent 1) (debug if-let))
    (list 'if-let bindings (macroexp-progn body)))

+(defmacro while-let (bindings &rest body)
+  "Process BINDINGS and eval BODY while all values are non-nil.
+Argument BINDINGS is a list of tuples whose car is a symbol to be
+bound and (optionally) used in BODY, and its cadr is a sexp to be
+evalled to set symbol's value.  In the special case you only want
+to bind a single value, BINDINGS can just be a plain tuple."
+  (declare (indent 1) (debug t))
+  `(while (when-let ,bindings (prog1 t ,@body))))
+
  (defsubst hash-table-empty-p (hash-table)
    "Check whether HASH-TABLE is empty (has 0 elements)."
    (zerop (hash-table-count hash-table)))
-- 
2.11.0

Re: Anaphoric macros: increase visibility

[Michael Heerdegen]

Hi Tino,

> I wonder if it has sense to increase that family with a while-let
> (maybe others in case they are useful).
>
> From 60f26b512b191add12a0c91dc4d7ff95aba080d9 Mon Sep 17 00:00:00 2001
> From: Tino Calancha <tino.calancha@gmail.com>
> Date: Sat, 14 Jan 2017 14:25:42 +0900
> Subject: [PATCH] * lisp/emacs-lisp/subr-x.el (while-let): New macro.

Maybe.  I'm using `when-let' and `if-let' a lot, but I'm still not sure
in which direction we should develop this approach.  I personally prefer
`when-let' and `if-let' over `awhen' and `aif'.  I sometimes think that
`if-let*' would be a better name for `if-let' because bindings can refer
(and naturally most of the time do) refer to other bindings.  I also
often think that `and-let' (or `and-let*' ...)  would be a better name
for `when-let' (because the expressions for the bindings are `and'ed,
sot the whole thing feels more like `and' to me).  And I often think
that it would be cool to couple them with pcase pattern matching.  OTOH
we already have `pcase-let', but I can't get along with its semantics,
e.g.

(pcase-let ((`(,a ,b) '(1 2 3)))
  (list a b))

==> (1 2)

although the pattern doesn't match.


Anyway, I think we should have an imagination of where the travel should
end before adding more *-let macros.


Regards,

Michael.

On the naming/behavior of {if, when}-let (was Re: Anaphoric macros: increase visibility)

[Mark Oteiza]

Michael Heerdegen <michael_heerdegen@web.de> writes:
> I sometimes think that
> `if-let*' would be a better name for `if-let' because bindings can refer
> (and naturally most of the time do) refer to other bindings.

There was a thread some time ago (I'd have to go dig for it) where
someone asked why the names lacked the *.  Seeing how they are
implemented on top of let*, this should be a no brainer, right?

Further, I think it's even more bizarre that if-let and when-let grew
the single tuple special case, where one can write

  (if-let (foo bar) (message "%S" foo) (message "oh no"))
          ^^^^^^^^^

What makes these binding things special? May as well add brackets and
whatever else from other lisps.

… and yet there is no _actual_ if-let to the effect of:

  (let ((a foo)
        (b bar))
    (if (and a b) 'yes 'no))

Though, for the above, I remember there being an argument against this
being useful.  IDK, I've written things like this before.

> I also
> often think that `and-let' (or `and-let*' ...)  would be a better name
> for `when-let' (because the expressions for the bindings are `and'ed,
> sot the whole thing feels more like `and' to me).

I'd also like an and-let* (presumably aliased to when-let*).

Re: Anaphoric macros: increase visibility

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> And I often think that it would be cool to couple them with pcase
> pattern matching.  OTOH we already have `pcase-let', but I can't get
> along with its semantics, e.g.
>
> (pcase-let ((`(,a ,b) '(1 2 3)))
>   (list a b))
>
> ==> (1 2)
>
> although the pattern doesn't match.

I think I would prefer something like

#+begin_src emacs-lisp
(defmacro pwhen (pairs &rest body)
  (declare (indent 1))
  `(pcase nil ((and ,@(mapcar (lambda (pair) (cons 'let pair)) pairs)) ,@body)))
#+end_src

This is similar to `when-let' but instead of a non-nil test, you can use
any test you want (via pattern matching).  There would not be an
implicit test for whether a matched expression evals to something
non-nil, however.

Example:

#+begin_src emacs-lisp
(defun test-pwhen (thing)
  (pwhen ((`(,x ,y)       thing)
          ((pred identity) x))
    (message "passed with x: %S and y:%S" x y)))
#+end_src

(test-pwhen 37)
   ==> nil
(test-pwhen '(1 2 3))
   ==> nil
(test-pwhen '(nil 32))
   ==> nil
(test-pwhen '(1 2))
   ==> "passed with x: 1 and y:2"


Michael.

Re: Anaphoric macros: increase visibility

[Tino Calancha]

Hi Michael,

>I sometimes think that `if-let*' would be a better name for `if-let'
>because bindings can refer (and naturally most of the time do) refer to other bindings.
+1

>I also often think that `and-let' (or `and-let*' ...)  would be a better name
>for `when-let' (because the expressions for the bindings are `and'ed,
>sot the whole thing feels more like `and' to me).
I am in the middle of the 2 names:
*) and-let* suggests me that the bindings are `and'ed
**) but when-let* suggests me that the second argument is a list of
     expressions, i.e., not just a form.

> (pcase-let ((`(,a ,b) '(1 2 3)))
>   (list a b))
>
> ==> (1 2)
>
> although the pattern doesn't match.
I can be bitten with that pitfall as well.

>I think I would prefer something like
>
>#+begin_src emacs-lisp
>(defmacro pwhen (pairs &rest body)
>  (declare (indent 1))
>  `(pcase nil ((and ,@(mapcar (lambda (pair) (cons 'let pair)) pairs)) ,@body)))
>#+end_src
It might be useful.

>I'm using `when-let' and `if-let' a lot, but I'm still not sure
>in which direction we should develop this approach.
>I think we should have an imagination of where the travel should
>end before adding more *-let macros.

A possible starting point is puting all together in
subr-x.el after a heading

;;; Anaphoric macros.

and perform the improvements in naming discussed in this thread:

1) Move `ibuffer-aif', `ibuffer-awhen' to subr-x.el and rename as
    `if-it', `when-it'.  Add aliases to them `aif', `awhen'.

2) `if-let' --> `if-let*'.  Add alias `if-let' for
    backward compatibility.

3) `when-let' --> `when-let*' (or `and-let*').  Add alias.

Once they are all together is easier to see what macro is missing
which could be useful.

Tino

Re: Anaphoric macros: increase visibility

[Stefan Monnier]

Tino writes:
>> (pcase-let ((`(,a ,b) '(1 2 3)))
>> (list a b))
>> ==> (1 2)
>> although the pattern doesn't match.
> I can be bitten with that pitfall as well.

I think the problem is in the name: it really should be called just `let`.
It does not do any *match*, instead the pcase pattern is only used to
specify how to *extract* the data we want.


        Stefan

Re: Anaphoric macros: increase visibility

[Tino Calancha]

On Sun, 15 Jan 2017, Stefan Monnier wrote:

> Tino writes:
>>> (pcase-let ((`(,a ,b) '(1 2 3)))
>>> (list a b))
>>> ==> (1 2)
>>> although the pattern doesn't match.
>> I can be bitten with that pitfall as well.
>
> I think the problem is in the name: it really should be called just `let`.
> It does not do any *match*, instead the pcase pattern is only used to
> specify how to *extract* the data we want.
I see.  Then, `pcase-let' is somehow similar than `-let' in dash.el.

Re: Anaphoric macros: increase visibility

[Stefan Monnier]

>> I think the problem is in the name: it really should be called just `let`.
>> It does not do any *match*, instead the pcase pattern is only used to
>> specify how to *extract* the data we want.
> I see.  Then, `pcase-let' is somehow similar than `-let' in dash.el.

That's right.  It's called `pcase-let` because it's in the `pcase`
package (because it uses pcase pattern syntax and implementation) and
hence must use the `pcase-` prefix.

The main advantage of the pcase pattern syntax is its regularity which
makes it extensible (see for example the (re-match REGEXP) pcase-macro
I recently posted which lets you match against a regexp and extract
submatches into variables at the same time).


        Stefan

Re: Anaphoric macros: increase visibility

[Dmitri Paduchikh]

Michael Heerdegen <michael_heerdegen@web.de> wrote:

> Tino Calancha <tino.calancha@gmail.com> writes:

>> Hi,
>>
>> I think anaphoric macros are a nice idiom; occasionally
>> they allow to write very concise and clear expressions.
>>
>> AFAICS, in the Emacs tree they are just introduced in ibuf-macs.el
>> (`ibuffer-aif', `ibuffer-awhen').

> We also already have `if-let' and `when-let' in "subr-x".  They are like
> `aif' and `awhen' but you specify "it" explicitly.

This explicitness argument seems to be standard criticism against anaphoric
macros. But it's easy to fix by providing new names for these macros: if-it,
when-it, and so on. Besides being more explicit these names are more readable
than aif and awhen. Comparing if-it, when-it with if-let, when-let, it seems
clear that they represent different tradeoffs of simplicity vs. flexibility.

With best regards
Dmitri Paduchikh

Re: Anaphoric macros: increase visibility

[Tino Calancha]

On Sat, 14 Jan 2017, Dmitri Paduchikh wrote:

>Comparing if-it, when-it with if-let, when-let, it seems
>clear that they represent different tradeoffs of simplicity vs. flexibility.
Do we need to choose?  We could have defined both kinds of anaphoric macros.
A) The simpler one is easier to read/understand.
B) The more flexible one allow us to write uniformly several related forms.

If i need > 1 binding i would use B), and if i just need one binding probably
i would rather prefer A).

>This explicitness argument seems to be standard criticism against anaphoric
>macros. But it's easy to fix by providing new names for these macros: if-it,
>when-it, and so on. Besides being more explicit these names are more readable
>than aif and awhen.
Although I prefer your names, i.e., if-it than aif, it might be argued that
there are historical reasons in favour of the latter.

Regards,
Tino

Re: Anaphoric macros: increase visibility

[Dmitri Paduchikh]

Tino Calancha <tino.calancha@gmail.com> wrote:

> On Sat, 14 Jan 2017, Dmitri Paduchikh wrote:

>>Comparing if-it, when-it with if-let, when-let, it seems
>>clear that they represent different tradeoffs of simplicity vs. flexibility.

> Do we need to choose?  We could have defined both kinds of anaphoric
> macros.

I am not disagree with that. Just wanted to note that existing names of
anaphoric macros are not best ones.

[...]

> Although I prefer your names, i.e., if-it than aif, it might be argued that
> there are historical reasons in favour of the latter.

Well, aif, awhen are at least more discoverable through C-h f aif for those
who used to these names. They can be aliases.

With best regards
Dmitri Paduchikh

Re: Anaphoric macros: increase visibility

[Michael Heerdegen]

Dmitri Paduchikh <dpaduchikh@gmail.com> writes:

> Well, aif, awhen are at least more discoverable through C-h f aif for
> those who used to these names. They can be aliases.

I think that would potentially cause confusion.

BTW, AFAIR the fact that `when-let' and `if-let' are not so discoverable
and hidden in subr-x was not unwanted because we wanted to experiment
with this stuff and see if we like it before we advertise it much.
There must be some discussion about this in the archives...


Michael.

Re: Anaphoric macros: increase visibility

[Dmitri Paduchikh]

Michael Heerdegen <michael_heerdegen@web.de> wrote:

> Dmitri Paduchikh <dpaduchikh@gmail.com> writes:

>> Well, aif, awhen are at least more discoverable through C-h f aif for
>> those who used to these names. They can be aliases.

> I think that would potentially cause confusion.

I meant making aif and awhen aliases to the proposed names if-it and when-it.
What confusion do you foresee?

With best regards
Dmitri Paduchikh

Re: Anaphoric macros: increase visibility

[Michael Heerdegen]

Dmitri Paduchikh <dpaduchikh@gmail.com> writes:

> I meant making aif and awhen aliases to the proposed names if-it and
> when-it.  What confusion do you foresee?

My own, I just misinterpreted your words, sorry.

Michael.