Arc Forumnew | comments | leaders | submitlogin
3 points by conanite 5462 days ago | link | parent

Macros are like compiler hooks, they are executed at compile time, not run-time. When you run code at the REPL, run-time is immediately after compile-time, so the difference is not obvious. Try this:

  arc> (mac amac () (prn "amac is reached"))
  #3(tagged mac #<procedure: amac>)
  arc> (def maybe-amac () (if t 1 (amac)))
  amac is reached
  #<procedure: maybe-amac>
  arc> (maybe-amac)
No "amac is reached" when you execute maybe-amac ...

I don't know how CL works internally, maybe it suppresses std-out from macros?

1 point by palsecam 5461 days ago | link

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))
   cl> (if t 1 (msleep 3))
   1    <-- answers immediately, CL doesn't suffer from oversleeping!

   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