Arc Forumnew | comments | leaders | submitlogin
1 point by palsecam 5623 days ago | link | parent

For CL, I don't know exactly how it works, but I suppose 'if is treated as a special form (or expand to a call to 'cond which is a special form, or something) which is in some way "higher in priority" than macro expanding.

I am really really not sure of that, but if I remember well my teachings, this is a part of the reasons why 'if or 'cond is a special form and not just a normal macro.

   > maybe it suppresses std-out from macros?
Now that would be crappy :-D! It is not just a problem of output, try the sleep macro example:

   cl> (defmacro msleep (time) (sleep time))
   MSLEEP
   cl> (if t 1 (msleep 3))
   1    <-- answers immediately, CL doesn't suffer from oversleeping!
Or:

   arc> (mac expect-arg-m (arg) arg)
   #3(tagged mac #<procedure: expect-arg-m>)
   arc> (expect-arg-m)
   Error: "procedure  expect-arg-m: expects 1 argument, given 0"  <-- OK, this is normal
   arc> (if t 1 (expect-arg-m))
   Error: "procedure  expect-arg-mac: expects 1 argument, given 0"  <-- hmm, parse the false clause...

   cl> (defmacro expect-arg-m (arg) arg)
   cl> (expect-arg-m)
   error while parsing arguments to DEFMACRO EXPECT-ARG-MAC:
   invalid number of element  <-- OK, normal
   cl> (if t 1 (expect-arg-m))
   1   <-- didn't bother to parse the false clause