emacs-devel
[Top][All Lists]
Advanced

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

RE: [External] : Re: [ELPA] New package: listen


From: Drew Adams
Subject: RE: [External] : Re: [ELPA] New package: listen
Date: Mon, 26 Feb 2024 17:17:26 +0000

Commenting only on the (minor) stylistic
convention you guys've discussed a bit -

> >> No, thanks.  I'm aware of this minor tradition,
> >> but I disagree with it.
> >
> > I wouldn't call it a minor tradition (e.g. in
> > Scheme the return value or `when' is unspecified.
> > CLtL2 says "If the value is relevant, then it
> > may be stylistically more appropriate to use and
> > or if."), and I am curious why you disagree with
> > it, but you are of course free to do as you want.
> 
> Well, Elisp isn't Scheme, and CLtL2 seems to
> say that it is exactly a minor tradition.  :)

It's not a tradition, minor or otherwise.
Never was, AFAIK.  It's one Lisp stylistic
approach/convention.  Dunno how widely it is,
was, or has been used, or in what contexts.

> I don't like it for a few reasons:

Very glad to see reasons!  Too much gets
discussed here without enough in the way of
reasons given, IMO.

> 1. Using AND puts the conditional expressions on the same level,
> visually and logically, as the value.  In contrast, using WHEN cleanly
> separates the condition(s) from the value.  IMO that's a significant
> advantage, as it makes the purpose of the code much clearer.

There's no separation of return value from
conditions in `when' - it simply always
returns `nil'.  It has only one condition,
the body has no bearing on the return value
(unless it `throw's etc.).

The visual separation of condition code and
body is irrelevant to the logical separation
of condition and return value.  The body's
irrelevant to the return value.

Your point that `and', `or', and `not' don't
separate the conditions from the result is
_precisely the point_.  These are Boolean
functions (with the particularity of ordered
evaluation).

With such a Boolean function - even a pure
one that returns only TRUE or FALSE - the
return value of any of the conditions _can
be_ the return value of the entire function.
Simple, elegant.

Of course, Lisp treats any non-nil value as
TRUE, so `and' and `or' (but not `not') can
return _any value whatsoever_.  Even _more_
simple and elegant.  That's Lisp, like it
or not.  (Most of us love it.)  

Think `member', as the classic example of
this leverage - exactly the same use case
as Lisp `and' and `or'.

> 2. WHEN's indentation also saves space, helping
> to avoid long lines or awkwardly wrapped ones.

OK.  So you prefer this:

(when (or xxxxxx
          yyyyyyyy
          zzzzzzzzz)
  foobar)

to this:

(or xxxxxx
    yyyyyyyy
    zzzzzzzzz)
    foobar)

saving 2 chars (or 3 for `and') in the foobar
indentation.

And I guess you prefer this:

(when
    foo
  bar)

to this?

(or
 foo
 bar)

wasting 1 char in the bar indentation.
___

Again, it's just a style/convention, and not
not one of the GNU Elisp coding conventions:

https://www.gnu.org/software/emacs/manual/html_node/elisp/Coding-Conventions.html

Let a hundred flowers bloom.  Different strokes
for different folks. ;-)

reply via email to

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