From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alex Shinn Newsgroups: gmane.lisp.guile.devel Subject: Re: Why not support (begin), (cond), (case-lambda), etc? Date: Fri, 6 Jan 2012 21:08:57 +0900 Message-ID: References: <871urdd593.fsf@netris.org> <87obuhbey2.fsf@netris.org> <87k455b6l2.fsf@netris.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1325851749 9759 80.91.229.12 (6 Jan 2012 12:09:09 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 6 Jan 2012 12:09:09 +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 13:09:04 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 1Rj8bX-00049O-MD for guile-devel@m.gmane.org; Fri, 06 Jan 2012 13:09:03 +0100 Original-Received: from localhost ([::1]:44408 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rj8bW-0004jJ-M8 for guile-devel@m.gmane.org; Fri, 06 Jan 2012 07:09:02 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:60735) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rj8bU-0004jE-4l for guile-devel@gnu.org; Fri, 06 Jan 2012 07:09:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rj8bS-000350-RX for guile-devel@gnu.org; Fri, 06 Jan 2012 07:09:00 -0500 Original-Received: from mail-ee0-f41.google.com ([74.125.83.41]:53850) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rj8bS-00034o-JO for guile-devel@gnu.org; Fri, 06 Jan 2012 07:08:58 -0500 Original-Received: by eekc41 with SMTP id c41so1099408eek.0 for ; Fri, 06 Jan 2012 04:08:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PRS4E6aAB8XOgdnmYsMv6bZvcu/2P35eGPzbELtyaLk=; b=ILZcHoWfMZB6Xk70gDp2Q0SFcn6TdXQWZiaPRBPaxNFs6cMfdxzA9DE4ps2Fse+Q0o 69DHLkZUVZZEtTBQNB8T07spwJJ530ANLA+fFAFi4s9TxXOrDrX0+AHpwzx93itkKM20 jMPcz0O5krTqZYjYtGfwsF6ITAk7bOccC3qOw= Original-Received: by 10.14.124.144 with SMTP id x16mr2206081eeh.110.1325851737614; Fri, 06 Jan 2012 04:08:57 -0800 (PST) Original-Received: by 10.213.5.6 with HTTP; Fri, 6 Jan 2012 04:08:57 -0800 (PST) In-Reply-To: <87k455b6l2.fsf@netris.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 74.125.83.41 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:13344 Archived-At: On Fri, Jan 6, 2012 at 5:03 PM, Mark H Weaver wrote: > > For example, consider a convenience macro to define a structure type. > It expands to a sequence of definitions, one of which is the > constructor. =A0In the structure specification, each field may provide an > optional `valid?' predicate. =A0One of the jobs of the constructor is to > make sure that its arguments are valid. > > One reasonable way to do this is to include a `cond' in the expansion of > the constructor which contains one clause for each field that provides > the optional `valid?' predicate. =A0This `cond' would be evaluated solely > for its effect, namely to raise an error if any predicate fails. > > However, the structure specification may not have included any field > predicates, in which case the macro would most naturally generate > (cond). Please take this to the scheme-reports list if you really want the standard changed. However, you would need actual macro examples to convince me. I can't see how you could arrive at the scenario you're describing. Assuming you've filtered out the fields that have predicates into pred-fields, then you would expand into something like: (define (constructor fields ...) (begin (expand-validate-field pred-fields) ... )) where each expand-validate-field would be something like (unless predicate (error "field predicate failed")) and possibly this would be inlined above instead of a separate macro. Alternately, if you don't want individual error messages but a single error then you expand into (define (constructor fields ...) (unless (and (expand-predicate pred-fields) ...) (error "some predicates failed")) ) where again there's no problem because the empty (and) is valid. I think the only reason to use cond would be the aesthetics of _not_ having any side-effecting expressions, i.e. you could expand into (define (constructor fields ...) (cond ((expand-predicate pred-fields) (error "invalid field")) ... (else ))) where the normal body is the "else" clause of the cond when no errors occurred, but in this case the cond is never empty (and always returns a value or errors). But I repeat, take this to the list, and polish up your arguments because you have to convince the whole group. > Of course, it is not hard to work around these seemingly pointless > prohibitions, just as it would not be hard to write > > =A0(if (null? xs) 0 (apply + xs)) > > instead of > > =A0(apply + xs) > > but I don't understand why we should have to. =A0What's the compelling > argument on the other side that justifies these annoyances? This analogy is meaningless, but for the record you should be using fold or reduce here. --=20 Alex