From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stuart D. Herring" Newsgroups: gmane.emacs.devel Subject: Re: constant `e' Date: Mon, 12 Feb 2007 10:51:57 -0800 (PST) Message-ID: <45285.128.165.123.18.1171306317.squirrel@webmail.lanl.gov> References: <87ireah6ia.fsf@wigwam.brockman.se> <854ppu8k1l.fsf@lola.goethe.zz> <87y7n6fdod.fsf@wigwam.brockman.se> <20070210135753.GB885@muc.de> <85hctt7w1j.fsf@lola.goethe.zz> Reply-To: herring@lanl.gov NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1171306345 8631 80.91.229.12 (12 Feb 2007 18:52:25 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 12 Feb 2007 18:52:25 +0000 (UTC) Cc: Alan Mackenzie , Daniel Brockman , emacs-devel@gnu.org To: "David Kastrup" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 12 19:52:17 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HGgHf-0004Z3-Tk for ged-emacs-devel@m.gmane.org; Mon, 12 Feb 2007 19:52:16 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HGgHe-0007Om-V6 for ged-emacs-devel@m.gmane.org; Mon, 12 Feb 2007 13:52:15 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HGgHS-0007Of-8z for emacs-devel@gnu.org; Mon, 12 Feb 2007 13:52:02 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HGgHR-0007OT-LS for emacs-devel@gnu.org; Mon, 12 Feb 2007 13:52:01 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HGgHR-0007OQ-Ia for emacs-devel@gnu.org; Mon, 12 Feb 2007 13:52:01 -0500 Original-Received: from mailwasher.lanl.gov ([192.65.95.54] helo=mailwasher-b.lanl.gov) by monty-python.gnu.org with esmtp (Exim 4.52) id 1HGgHQ-0004JP-86; Mon, 12 Feb 2007 13:52:00 -0500 Original-Received: from mailrelay2.lanl.gov (mailrelay2.lanl.gov [128.165.4.103]) by mailwasher-b.lanl.gov (8.13.8/8.13.8/(ccn-5)) with ESMTP id l1CIpxV9011328; Mon, 12 Feb 2007 11:51:59 -0700 Original-Received: from webmail1.lanl.gov (webmail1.lanl.gov [128.165.4.106]) by mailrelay2.lanl.gov (8.13.8/8.13.8/(ccn-5)) with ESMTP id l1CIpvLi024847; Mon, 12 Feb 2007 11:51:58 -0700 Original-Received: from webmail1.lanl.gov (localhost.localdomain [127.0.0.1]) by webmail1.lanl.gov (8.12.11.20060308/8.12.11) with ESMTP id l1CIpvVe030468; Mon, 12 Feb 2007 11:51:57 -0700 Original-Received: (from apache@localhost) by webmail1.lanl.gov (8.12.11.20060308/8.12.11/Submit) id l1CIpvGv030466; Mon, 12 Feb 2007 10:51:57 -0800 X-Authentication-Warning: webmail1.lanl.gov: apache set sender to herring@lanl.gov using -f Original-Received: from 128.165.123.18 (SquirrelMail authenticated user 196434) by webmail.lanl.gov with HTTP; Mon, 12 Feb 2007 10:51:57 -0800 (PST) In-Reply-To: <85hctt7w1j.fsf@lola.goethe.zz> User-Agent: SquirrelMail/1.4.8-2.el3.7lanl X-Priority: 3 (Normal) Importance: Normal X-PMX-Version: 4.7.1.128075 X-detected-kernel: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:66304 Archived-At: >>> Incidentally, I also think `(not (null n))' looks better than `n' --- >>> as do, I believe, most Emacs Lisp programmers. >> >> I disagree with you on both counts. When I see `(not (null n))', it >> takes extra effort mentally to filter out what, to me, is just >> noise. > > Agreed. More than agreement from me: if I see `(not (null n))' I immediately want to know what weird magic is going on that caused the author to need to add the extra function calls. I feel there must be something I don't understand about the code if the obvious approach was avoided. After all, would I be wrong in supposing that it is of some extraneous difficulty for you to understand (after reading) a sentence of words chosen in what is really a manner with excessive verbosity constructed without regard or consideration for either of brevity or the avoidance of redundant descriptions and clarifications? (Of course 'you' are understanding; of course "after reading", of course it's "of words"; why "regard" and "consideration", why "brevity" and "redundancy", why "descriptions" and "clarifications"? Why not "Isn't it harder to understand wordy, redundant sentences?") It's not just because there are many words to parse, but because they by their number and specificity suggest a complexity of meaning that simply isn't there. >>> Take a look at this code: >> >>> (cond (n >>> (bongo-mark-line-forward (prefix-numeric-value n))) >>> ((bongo-region-active-p) >>> (bongo-mark-region (region-beginning) (region-end))) >>> (t >>> (bongo-mark-line-forward))) >> >>> It's ugly, isn't it? It's not just that `(not (null n))' is >>> semantically clearer than a lone `n'; it's also more beautiful. All sorts of operations discard some of the information given them, such that the importance of that information is some subset of its normal meaning. Here, n is simplified to "nil or not nil", and you (Daniel) are suggesting that we should explicitly strip it down to that information before using it. If I were to write (< i 256), which discards i's lowest byte entirely, would you suggest that I write (zerop (lsh i -8)) just to make absolutely certain that I understood that I was discarding those bits? (And in so doing risk the sort of bug that has arisen here for negative i?) >> It's more alliterative, perhaps. But it feels like I'm being talked >> down to - the programmer is saying, in effect "you probably don't >> understand Lisp very well, so I'll make it very very clear". > > Disagree. That is not at all clearer. It is merely occupying a > different amount of space. > > Rather than "I'll make it very very clear", it is "I'll try to give > you a nice wallpaper that won't startle you out of your sleep". That may be true, but it also has an effect on the wakeful: it destroys the distinction that one of the conditions is a variable test, another is a function call, and the third is a special case. The visual information about the differences in complexity between the different branches is actually quite valuable; if I want contextual hints as to how to interpret them, I need only look at the `cond' word, which in my Emacs is nicely highlighted in (a low-key, non-bold) red to put beyond trivial determining the importance of the clauses. Davis -- This product is sold by volume, not by mass. If it appears too dense or too sparse, it is because mass-energy conversion has occurred during shipping.