From: Oleh Krehel <ohwoeowho@gmail.com>
To: Alan Mackenzie <acm@muc.de>
Cc: emacs-devel@gnu.org
Subject: Re: setq's with missing final arguments.
Date: Sun, 22 Nov 2015 13:35:45 +0100 [thread overview]
Message-ID: <87si3yp5y6.fsf@gmail.com> (raw)
In-Reply-To: <20151122122657.GA2332@acm.fritz.box> (Alan Mackenzie's message of "Sun, 22 Nov 2015 12:26:57 +0000")
Alan Mackenzie <acm@muc.de> writes:
> Consider this file:
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> (defvar foo t)
> (defvar bar t)
>
> (defun bad-setq ()
> "Doc string"
> (setq foo 5
> bar))
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>
> In the setq, there is a missing argument after "bar". At the moment,
> the byte compiler just generates code to assign nil to bar, without
> giving any warning. IMAO, this is Very Bad.
In my opinion, multi-variable setq should be deprecated altogether. I'm
sure many people will disagree for the reasons of habit, but
multi-variable setq is just plain bad: it makes LISP less lispy that it
should be. For example: "(setq bar)" is a nice sexp: you can delete it,
copy it, comment it, move it around - all kinds of fast, productive and
clear to see things. On the other hand, "bar" is simply a part of
another expression, you can do way less things with it, and you can
break things in bad ways if you're not careful. It's an unnecessary
mental burden on the programmer.
Just my two cents. I understand very well there's only 0.1% chance to
get this behavior deprecated because reasons. But a man can dream. And
at least I can enforce this restriction on the contributions to my
packages.
Oleh
next prev parent reply other threads:[~2015-11-22 12:35 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-22 12:26 setq's with missing final arguments Alan Mackenzie
2015-11-22 12:31 ` David Kastrup
2015-11-22 12:35 ` Oleh Krehel [this message]
2015-11-22 12:44 ` Teemu Likonen
2015-11-22 15:53 ` multi-assignment setq [was: setq's with missing final arguments.] Drew Adams
2015-11-23 7:58 ` Oleh Krehel
2015-11-23 15:02 ` Drew Adams
2015-11-22 12:52 ` setq's with missing final arguments Andreas Schwab
2015-11-22 13:03 ` Artur Malabarba
2015-11-22 13:08 ` David Kastrup
2015-11-22 13:11 ` Andreas Schwab
2015-11-22 13:23 ` David Kastrup
2015-11-22 13:34 ` Andreas Schwab
2015-11-22 14:10 ` Alan Mackenzie
2015-11-22 15:44 ` Eli Zaretskii
2015-11-22 19:44 ` Alan Mackenzie
2015-11-23 1:36 ` Drew Adams
2015-11-22 15:42 ` Johan Bockgård
2015-11-22 16:04 ` Drew Adams
2015-11-22 15:52 ` Drew Adams
2015-11-22 23:08 ` Alan Mackenzie
2015-11-22 23:20 ` John Wiegley
2015-11-23 1:54 ` Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87si3yp5y6.fsf@gmail.com \
--to=ohwoeowho@gmail.com \
--cc=acm@muc.de \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.