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
macro
that is called from another namespace?
On Monday, March 17, 2014 4:19:19 PM UTC+2, James Reeves wrote:
>
> 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,
he functions just accept s-expressions and return s-expressions. I
> find myself doing exactly that for nontrivial macros.
>
> Hope that helps,
> Maik
>
> On Mon, Mar 17, 2014 at 7:02 AM, Yoav Rubin >
> wrote:
> > Hi All,
> >
> > I have a namespace t
on'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,
from normal evaluation that happens from the
> inside out.
>
> Timothy
>
>
> On Mon, Mar 17, 2014 at 4:29 PM, Yoav Rubin
> > wrote:
>
>> Let's leave aside the recommendations not to do it. I'd like to
>> understand why I get the exception when I
uot; ~(str x) " with itself")
> ~(call-self x)))
>
> The function call-self* is still called at compile-time and is called *by
> the call-self macro*, not the generated client code. Make sense?
>
>
> On Monday, March 17, 2014 10:31:36 AM UTC-7, Yoav Rubin wrote:
&g
Hi,
Why not do things the other way around, and instead using partial to
curry the first argument, just repeat it as the second argument. i.e.,
(map + [1 2 3] (repeat 3)) . This approach seems to me as much more
readable and clean.
Yoav
On Dec 29, 4:22 pm, Jay Fields wrote:
> Sorry if this has