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] (
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
Don't use a private macro: use a function that spits out an s-expression.
- James
On 17 March 2014 06:02, Yoav Rubin yoavru...@gmail.com 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
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
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
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 yoavru...@gmail.com wrote:
I'm familiar
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
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
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 analyzes
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-self*
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 yoavru...@gmail.com wrote:
I need to do it, as I need the arguments to
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.
12 matches
Mail list logo
