From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24202 invoked by alias); 21 Aug 2009 04:30:01 -0000 Received: (qmail 24194 invoked by uid 22791); 21 Aug 2009 04:30:00 -0000 X-SWARE-Spam-Status: No, hits=-0.3 required=5.0 tests=AWL,BAYES_00,DNS_FROM_RFC_BOGUSMX X-Spam-Check-By: sourceware.org Received: from sebabeach.org (HELO sebabeach.org) (64.165.110.50) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 21 Aug 2009 04:29:53 +0000 Received: from sspiff.sspiff.org (seba.sebabeach.org [10.8.159.10]) by sebabeach.org (Postfix) with ESMTP id D8CD26E3D0; Thu, 20 Aug 2009 21:29:51 -0700 (PDT) Message-ID: <4A8E22BF.2080606@sebabeach.org> Date: Fri, 21 Aug 2009 04:30:00 -0000 From: Doug Evans User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Jim Blandy CC: cgen@sourceware.org Subject: Re: Opinions wanted: What should (.list pmacro-name 42) do? References: <4A8D8838.9090708@sebabeach.org> <8f2776cb0908201124h19b92065w313921eed3c46078@mail.gmail.com> In-Reply-To: <8f2776cb0908201124h19b92065w313921eed3c46078@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00067.txt.bz2 Jim Blandy wrote: > 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. The user asked for a list containing 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. That's what we do for symbols today >> (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? Hey Jim! Thanks for the feedback. I'm not quite sure what you mean, alas. [Apologies. I can guess, but ...] CGEN's pmacro system doesn't (currently) have quoting a la ' (or quote), btw. [The Scheme reader will accept it of course, but the pmacro system won't (currently) do anything sensible with (quote foo).] > 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. > Note that one can pass pmacros as parameters to other pmacros and invoke them. But the user is required to explicitly do this, CGEN won't (currently) take the result of a macro and rescan it for further pmacro invocations (except, currently, in the case where the result of the pmacro expansion is a single symbol). In Scheme the result of (list + 1 2) is ( 1 2), not 3. For reference sake, in Scheme, (define-macro (foo a) `(bar ,a)) (define-macro (bar a) `(baz ,a)) (foo 3) ;; expands to (bar 3) which in turn expands to (baz 3) In CGEN that would be (define-pmacro (foo a) (bar a)) (define-pmacro (bar a) (baz a)) Using pmacro-trace in Guile I get: guile> (pmacro-trace '(foo 3) (unspecified-location)) Pmacro expanding: (foo 3) Pmacro location: standard input:10:16 Expanding: (foo 3) env: () location: standard input:10:16 Expanding: (bar a) env: ((a . 3)) location: standard input:3:26 result: (baz 3) result: (baz 3) Pmacro result: (baz 3) (baz 3) And in Scheme, (define-macro (foo a) `(list bar ,a)) (define-macro (bar a) `(baz ,a)) (foo 3) ;; ==> (# 3) ;; Note that Scheme didn't re-expand the result and turn it into (baz 3). In CGEN, (define-pmacro (foo a) (.list bar a)) (define-pmacro (bar a) (baz a)) (foo 3) ;; ==> ( 3) We don't have to follow Scheme per se, but I'm worried that being excessively clever here will lead to issues (like in http://sourceware.org/ml/cgen/2009-q3/msg00052.html). One issue is: what if the user *wants* (.list foo 42) to be ( 42). S/he can always explicitly re-expand the expression to turn it into (add 42 1), e.g., with (.eval (.list foo 42)), but there's no (current) way to prevent the re-expansion if it was done automagically (unless, for example, we add a quoting system, which I hesitate to do in part because it's yet another complication to the language).