[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. ;-)
- Re: [ELPA] New package: listen, (continued)
- Re: [ELPA] New package: listen, Philip Kaludercic, 2024/02/25
- Re: [ELPA] New package: listen, Adam Porter, 2024/02/25
- Re: [ELPA] New package: listen, Philip Kaludercic, 2024/02/25
- Re: [ELPA] New package: listen, Adam Porter, 2024/02/25
- Re: [ELPA] New package: listen, Philip Kaludercic, 2024/02/26
- Re: [ELPA] New package: listen, Adam Porter, 2024/02/26
- Re: [ELPA] New package: listen, Philip Kaludercic, 2024/02/26
- Re: [ELPA] New package: listen, Adam Porter, 2024/02/26
- Re: [ELPA] New package: listen, Philip Kaludercic, 2024/02/26
- Re: [ELPA] New package: listen, Adam Porter, 2024/02/26
- RE: [External] : Re: [ELPA] New package: listen,
Drew Adams <=
- Re: [External] : Re: [ELPA] New package: listen, Philip Kaludercic, 2024/02/26
- RE: [External] : Re: [ELPA] New package: listen, Drew Adams, 2024/02/26
- Re: [External] : Re: [ELPA] New package: listen, Adam Porter, 2024/02/26
- RE: [External] : Re: [ELPA] New package: listen, Drew Adams, 2024/02/26
- Re: [External] : Re: [ELPA] New package: listen, Stephen Berman, 2024/02/26
- Re: [ELPA] New package: listen, Andreas Schwab, 2024/02/25
- Re: [ELPA] New package: listen, Adam Porter, 2024/02/25
- Re: [ELPA] New package: listen, Philip Kaludercic, 2024/02/26