Am I missing something? I thought this might be a bug in clisp, but I
get the same result in ACL, too...
(defmacro test (s)
`(progn
(print ,s)
,(if s
t
nil)))
(defun foo (&key x)
(test x))
CL-USER> (test t)
T
T
CL-USER> (test nil)
NIL
NIL
CL-USER> (foo)
NIL
T
CL-USER>
;nick
On 2007-02-03 20:28:48 +0100, ········@gmail.com said:
> (defmacro test (s)
> `(progn
> (print ,s)
> ,(if s
> t
> nil)))
CL-USER 2 > (macroexpand-1 '(test x))
(PROGN (PRINT X) T)
T
Michal
+ ········@gmail.com:
| Am I missing something? I thought this might be a bug in clisp, but I
| get the same result in ACL, too...
|
| (defmacro test (s)
| `(progn
| (print ,s)
| ,(if s
| t
| nil)))
|
| (defun foo (&key x)
| (test x))
The macro is expanded at function definition time, not when the
function is called. Since
(macroexpand-1 '(test x)) => (progn (print x) t)
the above function definition is equivalent to
(defun foo (&key x)
(progn (print x) t))
So the following is no longer a suprise. OK?
| CL-USER> (foo)
|
| NIL
| T
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
On Feb 3, 11:54 am, Harald Hanche-Olsen <······@math.ntnu.no> wrote:
> + ········@gmail.com:
>
> | Am I missing something? I thought this might be a bug in clisp, but I
> | get the same result in ACL, too...
> |
> | (defmacro test (s)
> | `(progn
> | (print ,s)
> | ,(if s
> | t
> | nil)))
> |
> | (defun foo (&key x)
> | (test x))
>
> The macro is expanded at function definition time, not when the
> function is called.
ok, right. It behaves correctly now when TEST is written as
(defmacro test (s)
`(progn
(print ,s)
(if ,s
t
nil)))
still, the fact that it assumed S is non null just because it was
supplied doesn't seem quite right...
take care
Nick
Since
>
> (macroexpand-1 '(test x)) => (progn (print x) t)
>
> the above function definition is equivalent to
>
> (defun foo (&key x)
> (progn (print x) t))
>
> So the following is no longer a suprise. OK?
>
> | CL-USER> (foo)
> |
> | NIL
> | T
>
> --
> * Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
> - It is undesirable to believe a proposition
> when there is no ground whatsoever for supposing it is true.
> -- Bertrand Russell
········@gmail.com wrote:
> On Feb 3, 11:54 am, Harald Hanche-Olsen <······@math.ntnu.no> wrote:
>
>>+ ········@gmail.com:
>>
>>| Am I missing something? I thought this might be a bug in clisp, but I
>>| get the same result in ACL, too...
>>|
>>| (defmacro test (s)
>>| `(progn
>>| (print ,s)
>>| ,(if s
>>| t
>>| nil)))
>>|
>>| (defun foo (&key x)
>>| (test x))
>>
>>The macro is expanded at function definition time, not when the
>>function is called.
>
>
> ok, right. It behaves correctly now when TEST is written as
>
> (defmacro test (s)
> `(progn
> (print ,s)
> (if ,s
> t
> nil)))
>
> still, the fact that it assumed S is non null just because it was
> supplied doesn't seem quite right...
You still have not achieved Bifurcation of the Two Times, or B2T. There
is compile-time and run-time. As others have pointed out, "it" did not
assume S is non-null, S was /at compile time/ precisely non-null, in
fact the symbol 'X. The assumption of which you speak is (subtext
expanded) "it assumed S [would be] non-null [at run time]". In fact,
"it" makes no speculation as to runtime. The macro function produced by
defmacro is tasked only with looking at the input source code arriving
as arguments.
You can enhance your B2T instinct (necessary for serious macro writing)
by putting print statements in the test macro outside the code returned:
(defmacro test (s)
(format t "~&Test received ~a, type ~a" s (type-of s))
... etc...
When you /compile/ foo you will get your debug output. That is
enlightment (and Time) Number One. The debug output will drive home the
above. When you run foo (compiled) you will not get debug output. That
is E2 and T2.
Advanced: Make it (test 'x) for fun and laughs. Try guessing the type
before trying it though. Yer a better Lispnik than me if you come close.
hth,kzo
--
Well, I've wrestled with reality for 35 years, Doctor, and
I'm happy to state I finally won out over it.
-- Elwood P. Dowd
In this world, you must be oh so smart or oh so pleasant.
-- Elwood's Mom
Dnia 03.02.2007 ········@gmail.com <········@gmail.com> napisa�/a:
> ok, right. It behaves correctly now when TEST is written as
>
> (defmacro test (s)
> `(progn
> (print ,s)
> (if ,s
> t
> nil)))
>
> still, the fact that it assumed S is non null just because it was
> supplied doesn't seem quite right...
Note, however, that here you double-evaluate the form S, so for example
the following won't work as expected:
(let (x)
(test (setf x (not x))))
--
Daniel 'Nathell' Janus, GG #1631668, ············@nathell.korpus.pl
"Though a program be but three lines long, someday it will have to be
maintained."
-- The Tao of Programming
+ ········@gmail.com:
| still, the fact that it assumed S is non null just because it was
| supplied doesn't seem quite right...
It assumed nothing of the sort. S was the symbol X, which is not
null. No assumptions required for that.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
········@gmail.com writes:
> On Feb 3, 11:54 am, Harald Hanche-Olsen <······@math.ntnu.no> wrote:
>> + ········@gmail.com:
>>
>> | Am I missing something? I thought this might be a bug in clisp, but I
>> | get the same result in ACL, too...
>> |
>> | (defmacro test (s)
>> | `(progn
>> | (print ,s)
>> | ,(if s
>> | t
>> | nil)))
>> |
>> | (defun foo (&key x)
>> | (test x))
>>
>> The macro is expanded at function definition time, not when the
>> function is called.
>
> ok, right. It behaves correctly now when TEST is written as
>
> (defmacro test (s)
> `(progn
> (print ,s)
> (if ,s
> t
> nil)))
>
> still, the fact that it assumed S is non null just because it was
> supplied doesn't seem quite right...
It didn't assume that S was non null, it tested and saw that S was
bound to the symbol X which obviously is not the symbol NIL.
Anyways, now you have the problem that (test (incf i)) will increment
i twice.
(defmacro test (expression)
`(not (not (print ,expression)))
But now it should be obvious that you don't need a macro here, but a
simple function.
(defun test (value)
(not (not (print value))))
Why did you believe you needed a macro in the first place?
--
__Pascal Bourguignon__ http://www.informatimago.com/
Pour moi, la grande question n'a jamais �t�: �Qui suis-je? O� vais-je?�
comme l'a formul� si adroitement notre ami Pascal, mais plut�t:
�Comment vais-je m'en tirer?� -- Jean Yanne
On Feb 3, 2:05 pm, Pascal Bourguignon <····@informatimago.com> wrote:
> ········@gmail.com writes:
> > On Feb 3, 11:54 am, Harald Hanche-Olsen <······@math.ntnu.no> wrote:
> >> + ········@gmail.com:
>
> >> | Am I missing something? I thought this might be a bug in clisp, but I
> >> | get the same result in ACL, too...
> >> |
> >> | (defmacro test (s)
> >> | `(progn
> >> | (print ,s)
> >> | ,(if s
> >> | t
> >> | nil)))
> >> |
> >> | (defun foo (&key x)
> >> | (test x))
>
> >> The macro is expanded at function definition time, not when the
> >> function is called.
>
> > ok, right. It behaves correctly now when TEST is written as
>
> > (defmacro test (s)
> > `(progn
> > (print ,s)
> > (if ,s
> > t
> > nil)))
>
> > still, the fact that it assumed S is non null just because it was
> > supplied doesn't seem quite right...
>
> It didn't assume that S was non null, it tested and saw that S was
> bound to the symbol X which obviously is not the symbol NIL.
Right, right. I don't know what I was thinking this morning. Thanks to
everyone for setting me straight so fast.
>
> Anyways, now you have the problem that (test (incf i)) will increment
> i twice.
>
> (defmacro test (expression)
> `(not (not (print ,expression)))
>
> But now it should be obvious that you don't need a macro here, but a
> simple function.
>
> (defun test (value)
> (not (not (print value))))
>
> Why did you believe you needed a macro in the first place?
>
Oh God, really? Double evaluation? I probubly shouldn't be naming
production-quality functions/macros TEST or FOO either. Next time I'll
make a simplified version of the problem so as not to distract you
with the other details of the problem.
;-)
Nick
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
>
> Pour moi, la grande question n'a jamais été: «Qui suis-je? Où vais-je?»
> comme l'a formulé si adroitement notre ami Pascal, mais plutôt:
> «Comment vais-je m'en tirer?» -- Jean Yanne- Hide quoted text -
>
> - Show quoted text -