From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32724 invoked by alias); 20 Aug 2009 18:24:32 -0000 Received: (qmail 32705 invoked by uid 22791); 20 Aug 2009 18:24:30 -0000 X-SWARE-Spam-Status: No, hits=-1.2 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from qw-out-1920.google.com (HELO qw-out-1920.google.com) (74.125.92.146) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 20 Aug 2009 18:24:23 +0000 Received: by qw-out-1920.google.com with SMTP id 5so189587qwf.24 for ; Thu, 20 Aug 2009 11:24:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.19.149 with SMTP id a21mr23726qcb.29.1250792660866; Thu, 20 Aug 2009 11:24:20 -0700 (PDT) In-Reply-To: <4A8D8838.9090708@sebabeach.org> References: <4A8D8838.9090708@sebabeach.org> Date: Thu, 20 Aug 2009 18:24:00 -0000 Message-ID: <8f2776cb0908201124h19b92065w313921eed3c46078@mail.gmail.com> Subject: Re: Opinions wanted: What should (.list pmacro-name 42) do? From: Jim Blandy To: Doug Evans Cc: cgen@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact cgen-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cgen-owner@sourceware.org X-SW-Source: 2009-q3/txt/msg00066.txt.bz2 On Thu, Aug 20, 2009 at 10:30 AM, Doug Evans wrote: > Hi. > > What should the output of > > (define-pmacro (foo a) (add a 1)) > (.list foo 42) > > be? > > Currently the result is ( 42) > where is the pmacro object for "foo". > > It's not ideal because it means that a pmacro object "escapes" > pmacro-processing and can be seen by, for example, rtl compilation. > > However, it's not that unexpected. =A0The user asked for a list containin= g two > objects, the pmacro and 42. > This is akin to saying (list + 42) in Scheme. > > We *could* have the pmacro evaluator re-examine the result and if it sees > ( mumble) then re-expand it. =A0That's what we do for symbols tod= ay > (i.e. if the result of pmacro-expansion is a symbol that names a pmacro, = we > re-evaluate it), but that has problems, e.g. > http://sourceware.org/ml/cgen/2009-q3/msg00052.html > and I'm leaning toward removing that behavior. Macros should definitely be able to expand to calls to other macros somehow; doesn't (.list 'foo 42) do this? If it does, then I don't see much point in allowing (.list foo 42) to do so as well. The source world and the value world need to interact only in easy-to-reason-about ways, or you end up with stuff like m4, which is just chaos. This reminds me of the "3-d macro" problem in Scheme, where macros can place values that can't actually be written in Scheme source code (procedure objects, say) into the tree that the compiler eventually sees. I've always thought the cleanest thing was to reject such code, as it didn't seem useful, and made a weird breach between macro expansion time and run time.