I think you're missing an important part:
We're saying that you can take your third, private helper macro, and turn
it into a private helper function. If you invoke it at compile time from
the public macros, it will receive the unevaluated forms you want, and be
able to transform the unevaluated
The case is that there are two public macro that call the same private
helper macro, and that private macro is the one who does the heavy lifting,
so I can either duplicate that private macro's code to be inside the public
macros, or make it public and mark it somehow with a "do-not-touch" sign.
You can call functions within the macro body without the arguments to the
macro being evaluated. If this wasn't the case, you'd be very limited in
how you could transform code.
- James
On 17 March 2014 17:31, Yoav Rubin wrote:
> I need to do it, as I need the arguments to remain not evaluated
You don't have the macro generate a call to the private function, you have
the macro call the private function directly
replace:
(defmacro call-self* [x]
`(~x ~x))
(defmacro call-self [x]
`(do
(println "calling form " ~(str x) " with itself")
(call-self ~x)))
with:
(defn- call-sel
Thanks - that's just what I needed to know :-)
On Tuesday, March 18, 2014 12:40:36 AM UTC+2, tbc++ wrote:
>
> The problem is in the way lisp compilers work. Example:
>
> The public macro gets analyzed first and runs, and emits the code required
> to call the private macro. Then the compiler analy
The problem is in the way lisp compilers work. Example:
The public macro gets analyzed first and runs, and emits the code required
to call the private macro. Then the compiler analyzes the output of the
first macro and discovers that the code now calls a new macro. It analyzes
this code and finds
Let's leave aside the recommendations not to do it. I'd like to understand
why I get the exception when I make such a call (from a public macro to a
private macro), and if it is possible, what am I doing wrong here...
On Monday, March 17, 2014 7:40:42 PM UTC+2, tbc++ wrote:
>
> Don't use private
Don't use private vars. Instead move the macro to a sub namespace called
"internals" or "impl" or something like that and make it public. Prefer
trusting your users instead of limiting them.
my $0.02
Timothy
On Mon, Mar 17, 2014 at 11:33 AM, Yoav Rubin wrote:
> I'm familiar with that trick, b
I'm familiar with that trick, but is it a language feature (and then I can
rely on to not being changed in the future)? or is it a hack that based on
something that may change in future releases?
Thanks,
Yoav
On Monday, March 17, 2014 4:09:23 PM UTC+2, Maik Schünemann wrote:
>
> Hi,
> I guess
I need to do it, as I need the arguments to remain not evaluated until they
get to that private macro. That private macro does some work on the
arguments before they get evaluated (the arguments themselves are
s-expressions).
Still, even if it is a private function - how can I call it from a ma
Don't use a private macro: use a function that spits out an s-expression.
- James
On 17 March 2014 06:02, Yoav Rubin wrote:
> Hi All,
>
> I have a namespace that has two macros as part of its public API, and
> another macro that act as helpers for the public macro
>
> (defmacro helper-mac [arg
Hi,
I guess that maybe the same trick works for calling private functions
from another namespace via getting the var and calling it.
That being said, macros calling macros gets very complex after a short
time, it is better to have helper functions instead of macros.
The functions just accept s-expr
Hi All,
I have a namespace that has two macros as part of its public API, and
another macro that act as helpers for the public macro
(defmacro helper-mac [arg1 arg2 f]
;; do stuff with f , arg1 and arg2
)
(defmacro m0 [arg1 arg2]
(priv-mac arg1 arg2 f1)
)
(defmacro m1 [arg1 arg2] (
(priv
13 matches
Mail list logo
