> Maybe the reader does _not_ eagerly resolve "c/foo" when the top-level
> enclosing form is a "do", but it _does_ eagerly resolve "c/foo" when
> the top-level enclosing form is a function?
The two forms read are very similar:
coretest=> (read-string "(= 1
(do
(alias 'c 'coretest)
(c/foo true)))")
(= 1 (do (alias (quote c) (quote coretest)) (c/foo true)))
coretest=> (read-string "(do
(alias 'c 'coretest)
(c/foo true))")
(do (alias (quote c) (quote coretest)) (c/foo true))
so I don't think it's to do with the reader.
The trick is probably when c/foo is being resolved/dereferenced (to
call c/foo): 'c' doesn't yet exist in the former, but apparently does
in the latter.
In this case, it appears that a toplevel `do` is being flattened,
possibly by this code in eval:
if(form instanceof IPersistentCollection &&
Util.equals(RT.first(form), DO))
{
ISeq s = RT.next(form);
for(; RT.next(s) != null; s =
RT.next(s))
eval(RT.first(s));
return eval(RT.first(s));
}
else if(form instanceof IPersistentCollection
&& !(RT.first(form) instanceof Symbol
&& ((Symbol)
RT.first(form)).name.startsWith("def")))
{
FnExpr fexpr = (FnExpr)
analyze(C.EXPRESSION, RT.list(FN, PersistentVector.EMPTY, form),
"eval");
IFn fn = (IFn) fexpr.eval();
return fn.invoke();
}
else
{
Expr expr = analyze(C.EVAL, form);
return expr.eval();
}
}
which -- to me -- reads as "if you're a toplevel do, eval each form in
turn; otherwise, eval the whole expression".
That's pure speculation, of course.
--
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
