Thanks Laurent.
It does give me an overall view, but more importantly it gives me the
impression that there are some subtleties, so I am not feeling so bad
about the fact some of the behaviour hasn't been what I had predicted.
On May 26, 1:55 pm, Laurent PETIT <laurent.pe...@gmail.com> wrote:
> Hi,
>
> 2010/5/26 Quzanti <quza...@googlemail.com>
>
> > Hi,
>
> > As a newbie to lisp/clojure one thing I am having real trouble with is
> > understanding macro expand time (now having discovered the difference
> > between quote and backquote I was hoping I was on the way to nirvana
> > but still trip up)
>
> > Some newbie questions:
>
> > If the macro is run at compile time how can it call functions - or can
> > it only call functions that you can guarantee will already have been
> > compiled
>
> Yes.
>
> > - so if you have macros calling functions in each other's
> > namespaces would the compiler have to compile part of one namespace
> > file, then part of the other, then back to the first?
>
> No, the compiler will not even be as smart as you describe. It's the (:use)
> (:require) (:load) declarations which will have taken place before the macro
> is invoked (generally inside an (ns) declaration) that would have made the
> required other functions / macros available.
>
> > If there is any error in your file below the macro, will the macro
> > have been expanded before the compiler discovers this? Or is there a
> > first pass for syntax before the main compile time. So what exactly is
> > compile time?
>
> The compiler will take each "top level form" one after the other :
> * read one form from the "input stream" (it will then get the famous
> "code-as-data"),
> * evaluate it: if the "code-as-data" starts with a list, we face a
> function call, so first resolve the function; if it is a real function, then
> first evaluate its arguments then pass them to the function; if it is a
> macro, then pass the arguments non-evaluated to the macro definition and
> substitute the whole macro call with the "code-as-data" returned by the
> macro ; if it is a special form, then execute the special form behaviour
> ('def has a side effect of creating a new var in the current namespace, 'fn
> has a side effect of compiling in memory (and on disk if *compile* is true)
> the function it defines, etc.
>
> This is certainly not accurate, but hopefully it gives you an overall view
> of the mechanisms.
>
> So the "first pass" is getting just enough information for evaluating the
> next "form" in the stream.
>
> HTH,
>
> --
> Laurent
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
