From: Big G
Subject: Macro question (technical)
Date:
Message-ID: <32C24DD5.7B51@en.com>
Sorry for the new-lisp-user-dumb-question (this appears to be a philosphy
of lisp newsgroup?), but I have a technical question regarding macros. I am
trying to substitute a list of conditions to a let statement.
------------------------
; Here's the code I am trying
(defvar conditions '((a 1) (b 2)))
(defmacro test-fun (x)
`(let (,x)
(print a)
(print b)
)
)
(test-fun conditions)
-------------------------
; I expect (test-fun conditions) to behave like this:
(let ((a 1) (b 2))
(print a)
(print b)
)
-------------------------
I expect this to print
1
2
but I get errors saying that a and b are undefined.
What gives? It appears that the macro substitution
isnt working. What am I doing wrong?
-G
Big G <·······@en.com> wrote:
> Sorry for the new-lisp-user-dumb-question (this appears to be a philosphy
> of lisp newsgroup?), but I have a technical question regarding macros. I am
> trying to substitute a list of conditions to a let statement.
> ------------------------
> ; Here's the code I am trying
>
> (defvar conditions '((a 1) (b 2)))
>
> (defmacro test-fun (x)
> `(let (,x)
> (print a)
> (print b)
> )
> )
>
> (test-fun conditions)
>
Try this:
(defmacro test-fun (x)
`(let ',x
(print a)
(print b)
)
)
The quote in front of the x is a regular quote, not a backquote.
I think it will work now. I didn't test it. Please don't ask me
to explain it, I can (or used to be able to) write double backquote
nested macros, but I could never explain how they work.
DDL
From: Big G
Subject: Re: Macro question (technical)
Date:
Message-ID: <32C2699B.10E0@en.com>
David Lowry wrote:
>
> Big G <·······@en.com> wrote:
> > Sorry for the new-lisp-user-dumb-question (this appears to be a philosphy
> > of lisp newsgroup?), but I have a technical question regarding macros. I am
> > trying to substitute a list of conditions to a let statement.
> > ------------------------
> > ; Here's the code I am trying
> >
> > (defvar conditions '((a 1) (b 2)))
> >
> > (defmacro test-fun (x)
> > `(let (,x)
> > (print a)
> > (print b)
> > )
> > )
> >
> > (test-fun conditions)
> >
>
> Try this:
>
> (defmacro test-fun (x)
> `(let ',x
> (print a)
> (print b)
> )
> )
>
> The quote in front of the x is a regular quote, not a backquote.
> I think it will work now. I didn't test it. Please don't ask me
> to explain it, I can (or used to be able to) write double backquote
> nested macros, but I could never explain how they work.
>
> DDL
I ended up doing this and it works!
Thanks for everyone's help. Note I used 'defun' and not 'defmacro'.
(defun test-fun (x)
(eval `(let ,x
(print a)
(print b))))
--
-Garrett
In article <·············@en.com>, Big G <·······@en.com> wrote:
]; Here's the code I am trying
]
](defvar conditions '((a 1) (b 2)))
]
](defmacro test-fun (x)
] `(let (,x)
] (print a)
] (print b)
] )
])
]
](test-fun conditions)
]
]-------------------------
]; I expect (test-fun conditions) to behave like this:
](let ((a 1) (b 2))
] (print a)
] (print b)
])
]
]
]-------------------------
]
]I expect this to print
]1
]2
]
]but I get errors saying that a and b are undefined.
]What gives? It appears that the macro substitution
]isnt working. What am I doing wrong?
The arguments to macros are not evaluated, since the purpose of macros is
to perform textual substitution. So the expansion of
(test-fun conditions)
is
(let (conditions)
(print a)
(print b))
You can use the MACROEXPAND function to see what the result of expanding a
macro is, e.g.
(macroexpand '(test-fun conditions))
should return what I wrote above (use (pprint (macroexpand ...)) to see it
formatted readably).
--
Barry Margolin
BBN Planet, Cambridge, MA
······@bbnplanet.com - Phone (617) 873-3126 - Fax (617) 873-5508
(BBN customers, please call (800) 632-7638 option 1 for support)
Big G <·······@en.com> writes:
>Sorry for the new-lisp-user-dumb-question (this appears to be a philosphy
>of lisp newsgroup?), but I have a technical question regarding macros. I am
>trying to substitute a list of conditions to a let statement.
comp.lang.lisp: Like Lisp. Code Lisp. Live Lisp.
Personally, I like the new-lisp-user-dumb-question because I'm a
dumb-new-lisp-user. :-)
>------------------------
>; Here's the code I am trying
>(defvar conditions '((a 1) (b 2)))
>(defmacro test-fun (x)
> `(let (,x)
> (print a)
> (print b)
> )
>)
>(test-fun conditions)
As someone else mentioned, during expansion the value of 'x' in
'conditions', and what you want is the value of 'conditions'.
So, I futzed about and came up with:
THE (not just any, but THE) new-lisp user ultra-faux pas.
Check this out:
(defmacro test-fun (x)
`(let ,(eval x)
(print a)
(print b)))
It works, but rumour has it that you'll go to Hell if you use it,
being its soiled with an 'eval'.
But, according to the CL Help that I was reading, inside of a
backquote, the ',' (comma) evaluates the form following it. But since
you wanted the value of the value of x (**x :-)), that was all I could
think of.
Now is a fine time for the Net Lisp Gods to smite me, and show The Way
and help pull both you and I from our personal purgatories.
I, humbly, await redemption.
--
Will Hartung - Rancho Santa Margarita. It's a dry heat. ······@netcom.com
1990 VFR750 - VFR=Very Red "Ho, HaHa, Dodge, Parry, Spin, HA! THRUST!"
1993 Explorer - Cage? Hell, it's a prison. -D. Duck
Will Hartung <······@netcom.com> wrote:
: Big G <·······@en.com> writes:
: >Sorry for the new-lisp-user-dumb-question (this appears to be a philosphy
: >of lisp newsgroup?),
*snort*choke* That is very funny! So much time here is spent on
language wars, we overlook more interesting things, like actual programming.
la
: but I have a technical question regarding macros. I am
: >trying to substitute a list of conditions to a let statement.
: Personally, I like the new-lisp-user-dumb-question because I'm a
: dumb-new-lisp-user. :-)
No such thing. Only a lisp user that hasn't seen all the light yet.
: >------------------------
: >; Here's the code I am trying
: >(defvar conditions '((a 1) (b 2)))
: >(defmacro test-fun (x)
: > `(let (,x)
: > (print a)
: > (print b)
: > )
: >)
: >(test-fun conditions)
This is a very strange thing to try to do. What's wrong with
(defun test-fun (a b)
(print a)
(print b))
If you're trying to learn about macros, though, that's fine. :)
: So, I futzed about and came up with:
: THE (not just any, but THE) new-lisp user ultra-faux pas.
: Check this out:
: (defmacro test-fun (x)
: `(let ,(eval x)
: (print a)
: (print b)))
: It works, but rumour has it that you'll go to Hell if you use it,
: being its soiled with an 'eval'.
Eek! You wont go to hell, but you'll make your compiler do
quite nasty things to your code. I believe non-free compilers require
a very hefty additional cost if you want to put (eval ...) into your
compiled code. And if you're compiler allows it, well, you're code
will be HUGE (that's GIGANTIC) because you'll have to have the entire
lisp interpreter in the object file.
: But, according to the CL Help that I was reading, inside of a
: backquote, the ',' (comma) evaluates the form following it. But since
: you wanted the value of the value of x (**x :-)), that was all I could
: think of.
Unfortunately, you're right on that. The original problem is
very strange, as I said above. Macros are for fiddling with your syntax,
and adding sugar to your code. The example above, well, it just makes
no since to my why you'd want to do that. I'd be very surprised if
anyone could come up with an example where they wanted an explicit
binding list to passed into a body of code in that way. That's what
function and macro *arguments* are for.
: Now is a fine time for the Net Lisp Gods to smite me, and show The Way
: and help pull both you and I from our personal purgatories.
: I, humbly, await redemption.
*snicker* I cannot too strongly recommend Paul Graham's book
"On Lisp" in which he devotes three chapters to the high art of macro
creation.
-----------------------------------------------------------------------
William Annis . ······@yar.cs.wisc.edu . http://dax.cs.wisc.edu/~wannis
entia no sunt multiplicanda praeter necessitatem
From: Big G
Subject: Re: Macro question (technical)
Date:
Message-ID: <32C4BCD8.1FA3@en.com>
>
> No such thing. Only a lisp user that hasn't seen all the light yet.
>
> : >------------------------
> : >; Here's the code I am trying
>
> : >(defvar conditions '((a 1) (b 2)))
>
> : >(defmacro test-fun (x)
> : > `(let (,x)
> : > (print a)
> : > (print b)
> : > )
> : >)
>
> : >(test-fun conditions)
>
> This is a very strange thing to try to do. What's wrong with
>
> (defun test-fun (a b)
> (print a)
> (print b))
>
> If you're trying to learn about macros, though, that's fine. :)
(I already have the answer to my problem.) The application I have is providing
lisp code fragments which are being fed into a lisp interpreter to make
decisions based on a list of specifications and a set of conditions which
must be met to evaluate to a success or failure. The example I provided
was a theoretical construct which models the kind of code/data being fed to
the interpreter.
-G
From: Big G
Subject: Re: Macro question (technical)
Date:
Message-ID: <32C4BEEC.5300@en.com>
William Annis wrote:
> No such thing. Only a lisp user that hasn't seen all the light yet.
>
> : >------------------------
> : >; Here's the code I am trying
>
> : >(defvar conditions '((a 1) (b 2)))
>
> : >(defmacro test-fun (x)
> : > `(let (,x)
> : > (print a)
> : > (print b)
> : > )
> : >)
>
> : >(test-fun conditions)
>
> This is a very strange thing to try to do. What's wrong with
>
> (defun test-fun (a b)
> (print a)
> (print b))
>
> If you're trying to learn about macros, though, that's fine. :)
> ...
> Unfortunately, you're right on that. The original problem is
> very strange, as I said above. Macros are for fiddling with your syntax,
> and adding sugar to your code. The example above, well, it just makes
> no [sense] to [me] why you'd want to do that. I'd be very surprised if
> anyone could come up with an example where they wanted an explicit
> binding list to passed into a body of code in that way. That's what
> function and macro *arguments* are for.
...
> -----------------------------------------------------------------------
> William Annis . ······@yar.cs.wisc.edu . http://dax.cs.wisc.edu/~wannis
> entia no sunt multiplicanda praeter necessitatem
I was trying to understand the general syntax for a code substitution problem
I encountered.
The application I am working on is providing lisp code fragments which are being fed
into a lisp interpreter to make decisions based on a list of specifications and a set
of conditions which must be met to evaluate to a success or failure. The example I
provided was a theoretical construct which models the kind of code/data being fed to
the interpreter. The 'print' statements are replacing lower level evaluations.
My problem description error was using 'conditions' instead of 'specifications' :)
-G
--
-Garrett
"If ifs and buts were candies and nuts, O what a Merry Christmas we'd
all have."
-Ohio State Head Coach John Cooper after the 28-0 loss to
Michigan in 1993.
"All these things I do, they're waiting for you."
-"Garden Grove", Sublime, 1996
In article <··········@spool.cs.wisc.edu> William Annis <······@cs.wisc.edu> writes:
: (defmacro test-fun (x)
: `(let ,(eval x)
: (print a)
: (print b)))
: It works, but rumour has it that you'll go to Hell if you use it,
: being its soiled with an 'eval'.
Eek! You wont go to hell, but you'll make your compiler do
quite nasty things to your code. I believe non-free compilers require
a very hefty additional cost if you want to put (eval ...) into your
compiled code.
But, since macro expansion is done at compile time, and since the eval
is inside the ,(...) the eval is done at expansion time, so it is not done
at run time. But there are other problems with eval - here is one:
USER(8): (let ((x '((a 3)(b 4))))
(TEST-FUN x))
Error: Attempt to take the value of the unbound variable `X'.
[condition type: UNBOUND-VARIABLE]
The problem is that eval does not see any lexical bindings.
If, as I understand from another post, the point is to construct
fairly random things at run time and evaluate them, then the primary
problem is not with eval, but with using macros in the first place.
Even if you do not have a compiler on your lisp, when thinking about
macros it is a useful heuristic to pretend that you do, and keep
firmly in mind that macros are expanded at compile time. You get into
trouble if you want a macro to expand into different things on different
calls to the function.
If you want to construct fairly random code at run time, eval might
actually be the right thing to use - but you have to construct a whole
function or be _very_ careful about the lexical binding issue illustrated
above.
However, even if you are constructing code, it is rarely "fairly
random" - it is usually quite stylized (e.g., the translation of a
query in some query language into lisp). If this is the case, there is
a better way to do things, using closures. To learn about this, you
should read "On Lisp" by Graham, in particular the sections on
working with closures.
In fact, anyone interested in lisp, macros, or closures should read
On Lisp. Also anyone interested in how Lisp is different from C or
Fortran.
From: Big G
Subject: Re: Macro question (technical)
Date:
Message-ID: <32C77C96.21F9@en.com>
Lou Steinberg wrote:
>
> In article <··········@spool.cs.wisc.edu> William Annis <······@cs.wisc.edu> writes:
>
> : (defmacro test-fun (x)
> : `(let ,(eval x)
> : (print a)
> : (print b)))
>
> : It works, but rumour has it that you'll go to Hell if you use it,
> : being its soiled with an 'eval'.
>
> Eek! You wont go to hell, but you'll make your compiler do
> quite nasty things to your code. I believe non-free compilers require
> a very hefty additional cost if you want to put (eval ...) into your
> compiled code.
>
> But, since macro expansion is done at compile time, and since the eval
> is inside the ,(...) the eval is done at expansion time, so it is not done
> at run time. But there are other problems with eval - here is one:
>
> USER(8): (let ((x '((a 3)(b 4))))
> (TEST-FUN x))
> Error: Attempt to take the value of the unbound variable `X'.
> [condition type: UNBOUND-VARIABLE]
>
> The problem is that eval does not see any lexical bindings.
>
This is a very interesting comment, because I found that when I tested
some of my variables with 'boundp()' (using XLISP) that the interpreter
gave me unbound-variable replies, althought I could work with them.
Still, I don't see any way around this, but I suppose I need to look into
this further if this becomes a serious problem. But even with this 'constraint',
using lisp to get the job done is infinetely better than trying to
do this in c++.
> If, as I understand from another post, the point is to construct
> fairly random things at run time and evaluate them, then the primary
> problem is not with eval, but with using macros in the first place.
> Even if you do not have a compiler on your lisp, when thinking about
> macros it is a useful heuristic to pretend that you do, and keep
> firmly in mind that macros are expanded at compile time. You get into
> trouble if you want a macro to expand into different things on different
> calls to the function.
>
> If you want to construct fairly random code at run time, eval might
> actually be the right thing to use - but you have to construct a whole
> function or be _very_ careful about the lexical binding issue illustrated
> above.
>
Well, I don't consider my constructs as being random, but I see your point
in general.
> However, even if you are constructing code, it is rarely "fairly
> random" - it is usually quite stylized (e.g., the translation of a
> query in some query language into lisp). If this is the case, there is
> a better way to do things, using closures. To learn about this, you
> should read "On Lisp" by Graham, in particular the sections on
> working with closures.
>
> In fact, anyone interested in lisp, macros, or closures should read
> On Lisp. Also anyone interested in how Lisp is different from C or
> Fortran.
--
-Garrett
"If ifs and buts were candies and nuts, O what a Merry Christmas we'd
all have."
-Ohio State Head Coach John Cooper after the 28-0 loss to
Michigan in 1993.
"All these things I do, they're waiting for you."
-"Garden Grove", Sublime, 1996
On Thu, Dec 26, 1996 2:05 AM, Big G <··············@en.com> wrote:
>; Here's the code I am trying
>
>(defvar conditions '((a 1) (b 2)))
>
>(defmacro test-fun (x)
> `(let (,x)
> (print a)
> (print b)
> )
>)
>
>(test-fun conditions)
>
>-------------------------
>; I expect (test-fun conditions) to behave like this:
>(let ((a 1) (b 2))
> (print a)
> (print b)
>)
>
>
>-------------------------
>
>I expect this to print
>1
>2
>
>but I get errors saying that a and b are undefined.
>What gives? It appears that the macro substitution
>isnt working. What am I doing wrong?
? (macroexpand '(test-fun conditions))
(LET (CONDITIONS) (PRINT A) (PRINT B))
T
Note that the name conditions is substituted literally.
Then look at this:
? (macroexpand '(test-fun ((a 1) (b 2))))
(LET (((A 1) (B 2))) (PRINT A) (PRINT B))
T
There's still an extra level of parens. But if you use
,@ instead of , (to "splice" the list into the expansion):
? (defmacro test-fun (x)
`(let (,@x)
(print a)
(print b)))
TEST-FUN
? (macroexpand '(test-fun ((a 1) (b 2))))
(LET ((A 1) (B 2)) (PRINT A) (PRINT B))
T
---------------------------------------------------------
David B. Lamkins --- http://www.teleport.com/~dlamkins/
---------------------------------------------------------
In article <·············@en.com>, Big G <·······@en.com> wrote:
...
>------------------------
>; Here's the code I am trying
>
>(defvar conditions '((a 1) (b 2)))
>
>(defmacro test-fun (x)
> `(let (,x)
> (print a)
> (print b)
> )
>)
>
>(test-fun conditions)
>
>-------------------------
>; I expect (test-fun conditions) to behave like this:
>(let ((a 1) (b 2))
> (print a)
> (print b)
>)
Lisp provides a way for you to test your expectations, by expanding the
macro..... [ cuting and pasting the above into Macintosh Common
Lisp ... a portion of my session with the Listener appear below. ]
? (pprint (macroexpand-1 '(test-fun conditions)))
(LET (CONDITIONS) (PRINT A) (PRINT B))
You see macros do not evaluate their arguments..... that's what makes
them different from functions. :-)
[ by habit I send the results of macroexpand-1 to pprint to make the
output slightly more readable... but that only necesary when the
expansion is rather lengthly and complex. ]
Also note that the symbol "conditions" above is enclosed within parens...
but the list bound to that symbol already has the enclosing parens neccessary
for the local definitions clause of the LET expression. Which leads to...
? (defmacro test-fun2 (x)
`(let ,(symbol-value x)
(print a)
(print b)
)
? (pprint (macroexpand-1 '(test-fun2 conditions)))
(LET ((A 1) (B 2)) (PRINT A) (PRINT B))
? (test-fun2 conditions )
1
2
2
Unless it is "necessary" to have the "conditions" hanging off a symbol
the following would work too..
(defun test-fun3 ( x)
`(let ,x
(print a)
(print b)
)
(test-fun3 (( a 1) (b 2)) )
No need to "quote" the conditions because macros don't evaluate their
arguments...
--
Lyman S. Taylor "We are Microsoft.
(·····@cc.gatech.edu) all other products are irrelevant.
resistance is futile.
Prepare to be assimilated."
.sig seen while netsurfing the Internet.
·····@cc.gatech.edu (Lyman S. Taylor) writes:
>In article <·············@en.com>, Big G <·······@en.com> wrote:
>>------------------------
>>; Here's the code I am trying
>>
>>(defvar conditions '((a 1) (b 2)))
>>
>>(defmacro test-fun (x)
>> `(let (,x)
>> (print a)
>> (print b)
>> )
>>)
>>
> Also note that the symbol "conditions" above is enclosed within parens...
> but the list bound to that symbol already has the enclosing parens neccessary
> for the local definitions clause of the LET expression. Which leads to...
> ? (defmacro test-fun2 (x)
> `(let ,(symbol-value x)
> (print a)
> (print b)
> )
> ? (pprint (macroexpand-1 '(test-fun2 conditions)))
> (LET ((A 1) (B 2)) (PRINT A) (PRINT B))
I chimed in early with an (eval ...) approach, and Brad Miller wrote me
offline asking about:
(let ((foo '((a 1) (b 2))))
(test-fun2 foo))
Since (eval ...) has only dynamic scope, it failed. But, using symbol-value
in the previous macro also fails, but for different reasons. I think
it has to do with when 'foo' gets bound (at run time) and when
(symbol-value ...) fires off (at compile time). A Macro subtlety that
I'm sure has claimed many a victim.
So, I don't think this macro will work with any symbol that is not in
the dynamic scope.
BTW, it's not like I KNEW any of this when this question first
surfaced. Thanks to Brad with his "What abouts" and "What ifs", I had
to dig deeper into what was really happening and, damnit, LEARN what
was going on. I always thought the 'net was the core supplier to the
instant-gratification "this sucks, change it!" generation.
So, thanks Brad for shattering my delusions! :-)
--
Will Hartung - Rancho Santa Margarita. It's a dry heat. ······@netcom.com
1990 VFR750 - VFR=Very Red "Ho, HaHa, Dodge, Parry, Spin, HA! THRUST!"
1993 Explorer - Cage? Hell, it's a prison. -D. Duck
In article <················@netcom.com>,
Will Hartung <······@netcom.com> wrote:
>Since (eval ...) has only dynamic scope, it failed. But, using symbol-value
>in the previous macro also fails, but for different reasons. I think
>it has to do with when 'foo' gets bound (at run time) and when
>(symbol-value ...) fires off (at compile time). A Macro subtlety that
>I'm sure has claimed many a victim.
Actually it's the same problem, not a different one.
"symbol-value cannot access the value of a lexical variable"
- Steele pg. 119
--
== Seth Tisue <·······@nwu.edu> http://www.cs.nwu.edu/~tisue/
In article <················@netcom.com>,
Will Hartung <······@netcom.com> wrote:
>·····@cc.gatech.edu (Lyman S. Taylor) writes:
>
>I chimed in early with an (eval ...) approach, and Brad Miller wrote me
>offline asking about:
>
> (let ((foo '((a 1) (b 2))))
> (test-fun2 foo))
>
>Since (eval ...) has only dynamic scope, it failed. But, using symbol-value
>in the previous macro also fails, but for different reasons. I think
>it has to do with when 'foo' gets bound (at run time) and when
>(symbol-value ...) fires off (at compile time). A Macro subtlety that
>I'm sure has claimed many a victim.
I'm not sure what "eval only has dynamic scope" means. EVAL only can use
symbols from the global environment. For instance the following doesn't work
? ( let ( ( foo 23 ))
(eval '(1+ foo)))
While global symbols are technically dynamically scoped, they
aren't the only dynamcially scoped symbols you can have.
The following will fail also ( and the symbol in question definitately have
"dynamic scope". Only not from the overall global environment. ).
(defun special-fun ( special-var )
(declare (special special-var ))
(special-fun-hlpr ))
(defun special-fun-hlpr ()
(declare (special special-var ))
(test-fun2 special-var ))
So therefore the "symbol-value" and "eval" approach fail for the same
reason. :-)
P.S. if the definitions of the original problem had be reordered the
same problem would occur
(defmacro test-fun ... )
(test-fun conditions ) ;; <- error would occur here as
;; file was loaded or compiled.
(defvar conditions .. )
--
Lyman S. Taylor "We are Microsoft.
(·····@cc.gatech.edu) all other products are irrelevant.
resistance is futile.
Prepare to be assimilated."
.sig seen while netsurfing the Internet.
In article <··········@pravda.cc.gatech.edu>,
Lyman S. Taylor <·····@cc.gatech.edu> wrote:
> I'm not sure what "eval only has dynamic scope" means. EVAL only can use
> symbols from the global environment.
Ooops.. since by habit I avoid dynamic scoping like the plague, I messed
this up. EVAL using the current dynamic scoped environment. However,
it is still the case that it isn't "dynamic scoping" isn't "why"
eval fails in the macro.
P.S. the following works. Reused framework from previous example
(defun special-fun ( special-var )
(declare (special special-var ))
(special-fun-hlpr ))
(defun special-fun-hlpr ()
(declare (special special-var ))
(eval '(1+ special-var )))
? (special-fun 23)
24
--
Lyman S. Taylor "I'm a Doctor, not a doorstop... "
(·····@cc.gatech.edu) The EMH Doctor in "Star Trek: First Contact".