Thanks. You guys are great. I get the reasoning and a work-around! It's not that it bothers me. I'm working on a compiler (for Jarc) and wanted to make sure it's okay to optimize away the thunk.
If Jarc still has the macro semantics I mentioned at http://arclanguage.org/item?id=11621, it may not be okay. That's because usually a call to a thunk suppresses the expansion of expressions inside it:
Jarc>
(mac bar ()
(do (prn "expanding")
4))
#3(tagged mac #<procedure>)
Jarc>
(def foo ()
(bar)
(prn 1)
(and (bar)) ; expands through '(bar) to 4
(prn 2)
(idfn (bar))
(prn 3)
(do (bar))) ; expands to '((fn nil (bar)))
expanding
expanding
#<procedure>
Jarc> (foo)
1
2
expanding
3
expanding
4
Jarc> (foo)
1
2
expanding
3
expanding
4
Jarc>
As you can see, (bar) in a function body is expanded to 4 as the function is defined, even if it's the result of expanding (and (bar)), but (do (bar)) is only expanded to ((fn () (bar))), and expansion stops here because it's a function application. In regular Arc, 'ac compiles function applications by compiling all their subexpressions, but apparently this doesn't happen in Jarc.
Like I touched upon in the other thread, if you were to "fix" this, that would break some of Jarc's ability to use lexically bound macros. Specifically, it would make it impossible to shadow a global macro with a local binding ('cause it would be compiled too soon). Lexically bound macros would still be available to an extent, since another two of Jarc's differences are that 'eval uses the lexical environment and that macro applications which somehow miss being compiled, like (let x bar (x)), are called with their arguments unevaluated (like fexprs).
On the other other hand, this fexpr ability kinda begs for function applications not to be compiled in all cases, or else what the fexpr sees will probably be the compiled arguments rather than the original ones.
Anyway, hope this helps you figure things out. ^_^
Jarc wasn't designed to allow lexically bound macros, that is just an accident of the current (broken!) implementation.
Jarc originally had dynamic binding, which is why eval uses the lexical environment. I should have changed that when I ripped out the dynamic binding. I'll fix eval. I'd like Jarc to be consistent with arc3.1
