From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ian Price Newsgroups: gmane.lisp.guile.devel Subject: Re: Why not support (begin), (cond), (case-lambda), etc? Date: Fri, 06 Jan 2012 16:53:31 +0000 Message-ID: <87ehvcn56c.fsf@Kagami.home> References: <871urdd593.fsf@netris.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1325869163 10631 80.91.229.12 (6 Jan 2012 16:59:23 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 6 Jan 2012 16:59:23 +0000 (UTC) Cc: guile-devel@gnu.org To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Jan 06 17:59:19 2012 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RjD8P-0000qc-N9 for guile-devel@m.gmane.org; Fri, 06 Jan 2012 17:59:17 +0100 Original-Received: from localhost ([::1]:41836 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RjD8P-0004fs-7H for guile-devel@m.gmane.org; Fri, 06 Jan 2012 11:59:17 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:39818) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RjD8L-0004fi-Ij for guile-devel@gnu.org; Fri, 06 Jan 2012 11:59:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RjD8K-0002MW-5M for guile-devel@gnu.org; Fri, 06 Jan 2012 11:59:13 -0500 Original-Received: from mail-we0-f169.google.com ([74.125.82.169]:58237) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RjD8J-0002MO-QW for guile-devel@gnu.org; Fri, 06 Jan 2012 11:59:12 -0500 Original-Received: by werf1 with SMTP id f1so1640279wer.0 for ; Fri, 06 Jan 2012 08:59:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=r5UTQwYsFvKvbg4aDfHaEZVBU8XxVleOJuOQL+/R2e0=; b=BnnHIKWZP0mY7lV6BmMmvSQgRY72bz6OmBqHoonVhG22HHkHnXh3/LwyW1COzRwGzc w900LjIltKIdiayV93Awt7PWroNNmEkzKx+4230e0/Ix8kadzudixpIDFKOo7wUQGIcn 4WqwRZj1hz725noiHPkPIF5InbzLp46o9jIpg= Original-Received: by 10.216.131.29 with SMTP id l29mr3431181wei.5.1325869150161; Fri, 06 Jan 2012 08:59:10 -0800 (PST) Original-Received: from Kagami.home (host86-171-77-216.range86-171.btcentralplus.com. [86.171.77.216]) by mx.google.com with ESMTPS id fd1sm3243485wib.0.2012.01.06.08.59.08 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 Jan 2012 08:59:09 -0800 (PST) In-Reply-To: <871urdd593.fsf@netris.org> (Mark H. Weaver's message of "Thu, 05 Jan 2012 19:49:44 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 74.125.82.169 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:13355 Archived-At: Mark H Weaver writes: > Hello all, > > I'd like to argue in favor of supporting (begin), (cond), (case-lambda) > and other such degenerate forms, for the same reason that we support > (*), (+), and (let () ...). > > First of all: Is there any compelling reason not to support them? > I can't think of one. Can you? If so, please do tell. For many of these forms it isn't as obvious what the value should be. For +,*,and,or you can use the identity element for these relations and that is perfectly nice and obvious, (let () ...), you can figure out by imagining ((lambda () ...)) which also seems obvious to me. begin, cond, and case-lambda are less obvious. I guess (unspecified, unspecified, a function that always produces a "wrong number of arguments" error). Also, if you're doing it for begin, do you think this should apply to all implicit begins? If I saw, for example, a lambda with definitions, but no expressions, I'd think the writer had made an error, rather than this being intentional. > Imagine if we didn't support (*) and (+). Then you couldn't simply > write (apply + xs) to add a list of numbers; instead you'd have to write > (if (null? xs) 0 (apply + xs)). In other words, they simplify > higher-order programming by freeing the user from handling degenerate > cases specially. In general, I agree, but it is important IMO to consider it on a case-by-case basis, and not just provide an arbitrary semantics for no-argument version. If you do that, then you aren't simplifying at all, but merely trading one set of complications for another. -- Ian Price "Programming is like pinball. The reward for doing it well is the opportunity to do it again" - from "The Wizardy Compiled"