On Wed, May 25, 2011 at 10:58 PM, Ken Wesson <kwess...@gmail.com> wrote:
> Different things happen at compile and run time in each case:
>
> Thing Compile Run
> literal inserted into bytecode recalled from memory
> symbol var resolved, deref compiled var is deref'd
> (def bar baz) bar var interned baz eval'd, bar set
> (macro x y) macro is expanded expansion is eval'd
> (func bar baz) fn-calling code compiled func called with args
Actually, I didn't include in there the literal set, vector, and map
case. There, the compiler emits code to evaluate the subforms and pass
them to the appropriate constructor to produce the set, vector, or
map; the runtime does the evaluation and construction. When the
collection literal has no non-self-evaluating nested forms, though,
it's possible the compiler optimizes this by simply emitting code to
retrieve the literal collection from memory somewhere.
There's also the subform evaluation matter:
Thing Subforms evaluated when?
[foo bar baz] at runtime, as arguments to vector constructor
#{foo bar} at runtime, as arguments to set constructor
{foo bar} at runtime, as arguments to map constructor
(def foo bar) foo isn't eval'd; bar eval'd to assign foo
(macro foo bar) at runtime, as decided by macro
(func foo bar) at runtime, before func called
Different special forms differ; e.g.
(if foo bar baz)
results in foo evaluated, and then either bar or baz depending on the
truthiness of whatever foo evaluated to.
Macros generally splice their argument forms into their expansion in
some manner, and the nature of that expansion determines what gets
called when. For example if -?> is defined to be a null-safe threading
macro, which acts like -> except that if any of the intermediate
results is nil it stops and evaluates to nil, then:
(-?> {:a 3}
(:b)
(+ 17))
will never evaluate the (+ something 17) clause because the result of
(:b {:a 3}) is nil.
The macro would expand this into something like:
(let [x {:a 3}]
(if x
(let [y (:b x)]
(if y
(+ y 17)))))
and then the rules for the special form (if ...) end up causing the (+
y 17) to not be evaluated.
--
Protege: What is this seething mass of parentheses?!
Master: Your father's Lisp REPL. This is the language of a true
hacker. Not as clumsy or random as C++; a language for a more
civilized age.
--
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
