From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.help Subject: Re: if vs. when vs. and: style question Date: Fri, 27 Mar 2015 01:31:05 +0100 Organization: Aioe.org NNTP Server Message-ID: <87bnjf8enq.fsf@debian.uxu> References: <87sicvwckx.fsf@wmi.amu.edu.pl> <87wq27yvqg.fsf@debian.uxu> <8d531e99-7260-4263-ac99-09c6871e2708@googlegroups.com> <87vbhq53lf.fsf@debian.uxu> <828c5115-a61b-4c42-b6d5-7bdcc6a691f0@googlegroups.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1427416237 9389 80.91.229.3 (27 Mar 2015 00:30:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 27 Mar 2015 00:30:37 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Mar 27 01:30:37 2015 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YbIAF-0003Fk-5H for geh-help-gnu-emacs@m.gmane.org; Fri, 27 Mar 2015 01:30:19 +0100 Original-Received: from localhost ([::1]:47063 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YbIAE-0007Wy-AT for geh-help-gnu-emacs@m.gmane.org; Thu, 26 Mar 2015 20:30:18 -0400 Original-Path: usenet.stanford.edu!goblin2!goblin.stu.neva.ru!aioe.org!.POSTED!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 86 Original-NNTP-Posting-Host: feB02bRejf23rfBm51Mt7Q.user.speranza.aioe.org Original-X-Complaints-To: abuse@aioe.org User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) X-Notice: Filtered by postfilter v. 0.8.2 Cancel-Lock: sha1:+Pbhpsvzcb3YVFmwkquDJhLMlAs= Mail-Copies-To: never Original-Xref: usenet.stanford.edu gnu.emacs.help:211091 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:103373 Archived-At: Rusi writes: > Pattern-matching in modern FPLs would be more > appropriate > > foo [] = bla foo (x:xs) = ble > > Can always be translated into > > foo l = if null l then bla else ble > > The reverse is of course not always possible But > when pattern matching works its preferable to > 'all-powerful' if-then-else > > Notice also that pattern matching is a mix of 3 > features that are usually separate -- 1. if 2. > let 3. car/cdr ie selectors Separately those 3 are > strictly more powerful than pattern matching And > thats what makes pattern matching preferable (when > it applies) Aha - even more of the old functional programming hysteria! Haskell, pattern matching... - are you sure you are in the right newsgroup? There is absolutely no rule that says "weak" constructs are preferable, and especially not when they are weak because they incorporate data that is otherwise (in the "strong" version) readily available to edit *as data* - i.e., exactly what it is. Compare: (defun insert-hello () (interactive) (insert-char ?h) (insert-char ?e) (insert-char ?l) (insert-char ?l) (insert-char ?o) ) (insert-hello) vs. (insert "hello") Instead, the way to think is that the code should talk both ways: it should tell the machine to do the correct computation, all the while while showing and indicating purpose to the person who writes and/or reads the code! For example, remember this example: (1+ data) vs. (+ 1 data) The "weak" vs. "strong" is the wrong way to think about it. In a discrete context, for example when iterating a data structure or doing recursion, the `1+' is preferable. When just adding two data items, of which one happens to be 1, the (+ 1 data) is better. Perhaps that '1' will soon change. Big part of the Lisp appeal is that it is so easy to change (tweak) everything as you go along, in the light of experience (which is often very recent), and then it goes on. Or perhaps the '1' appears again in some other place in the code, and when it does, the coder stops to think, and it is concluded that it is the same data item as the first one (ha) - i.e., both should be replaced by an binding or variable... -- underground experts united http://user.it.uu.se/~embe8573