From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/20843 Path: main.gmane.org!not-for-mail From: Hallvard B Furuseth Newsgroups: gmane.emacs.gnus.general Subject: Re: catch/throw Date: 02 Feb 1999 00:36:59 +0100 Sender: owner-ding@hpc.uh.edu Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035159062 19953 80.91.224.250 (21 Oct 2002 00:11:02 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 00:11:02 +0000 (UTC) Return-Path: Original-Received: from karazm.math.uh.edu (karazm.math.uh.edu [129.7.128.1]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id SAA25483 for ; Mon, 1 Feb 1999 18:38:03 -0500 (EST) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by karazm.math.uh.edu (8.9.1/8.9.1) with ESMTP id RAB22242; Mon, 1 Feb 1999 17:37:34 -0600 (CST) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Mon, 01 Feb 1999 17:37:51 -0600 (CST) Original-Received: from sclp3.sclp.com (root@sclp3.sclp.com [204.252.123.139]) by sina.hpc.uh.edu (8.7.3/8.7.3) with ESMTP id RAA21948 for ; Mon, 1 Feb 1999 17:37:43 -0600 (CST) Original-Received: from mons.uio.no (6089@mons.uio.no [129.240.130.14]) by sclp3.sclp.com (8.8.5/8.8.5) with SMTP id SAA25456 for ; Mon, 1 Feb 1999 18:37:35 -0500 (EST) Original-Received: from mons.uio.no (actually mons.uio.no [129.240.130.14]) by mons.uio.no with SMTP (PP); Tue, 2 Feb 1999 00:37:00 +0100 Original-Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.10 #1) id 107Sto-0001By-00; Tue, 2 Feb 1999 00:37:00 +0100 Original-Received: by bombur.uio.no ; Tue, 2 Feb 1999 00:36:59 +0100 (MET) Original-To: ding@gnus.org Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:20843 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:20843 Lars Magne Ingebrigtsen writes: > "Return non-nil if any of the elements are non-nil." > > where I would have written something like the following before: > > (defun gnus-or (&rest elems) > (let (found) > (while (and elems > (not found)) > (when (pop elems) > (setq found t))) > found)) What's wrong with this? (defun gnus-or (&rest elems) (while (and elems (null (car elems))) (setq elems (cdr elems))) (consp elems)) > I don't know. catch/throw has gives me the visceral thrill of being > able to say "I've found what I'm looking for! Stop iterating this > instance and return THIS! Right now!" You mean like this? (while (and (progn code ... continue?) (progn more code ... continue?) (progn more code ... continue?))) > But catch/throw is just goto under another name, isn't it? So are while and if. Like them, catch/throw is a structured goto: A block of code with one entry and one exit point, so it's easy to analyze the control flow. That's fine, except that it slows down elisp. > And doesn't one frown on goto? Unstructured goto, yes. Also, when a function contains a label, both the compiler and the human reader must search the entire function for goto-spaghetti. Both may have trouble analyzing the control flow. > (I'm assuming catch sets up an unwind-protect form, Yes. Well, more like condition-case, actually. > which probably isn't extremely efficient, True. For one thing, the body even of byte-compiled catch is evalled as a separate lisp form (so it gets a separate byte-code form). > (In Common Lisp, we have functions that make many of these types of > loops unnecessary, but I'm not allowed to use the cl functions in > Gnus.) You could always invent gnus-variants of some forms that do not need throw/catch:-) e.g. something like (gnus-while-cond (condition form...) (condition form...) ...) where the first failed condition test will terminate the loop. -- Hallvard