Sure, I was considering that anyway. I'm not sure, though, whether it
should be in its own library all by its lonesome or in one with at least a
fairly generic name, since I've got some other macro-related utilities
(specifically https://github.com/bwo/macroparser) that could all be
usefully (I thi
It looks like the macroexpansion code in conditions.free is fairly generic.
What would you say to putting it into its own library?
On Thu, Jul 11, 2013 at 6:54 PM, Ben Wolfson wrote:
> On Thu, Jul 11, 2013 at 6:48 PM, Zach Tellman wrote:
>
>> Yeah, for safety's sake I need to macroexpand ever
On Thu, Jul 11, 2013 at 6:48 PM, Zach Tellman wrote:
> Yeah, for safety's sake I need to macroexpand everything, which wipes out
> the &env for internal macros. There might be a gentler way to do this, but
> it's not obvious to me. If anyone has suggestions, I'd be interested in
> hearing them.
Yeah, for safety's sake I need to macroexpand everything, which wipes out
the &env for internal macros. There might be a gentler way to do this, but
it's not obvious to me. If anyone has suggestions, I'd be interested in
hearing them.
Zach
On Thursday, July 11, 2013 6:35:21 PM UTC-7, Ben wro
Note:
proteus> (defmacro aif [test then else]
(let [it (first (filter #(not (contains? &env %))
(cons 'it (map #(symbol (str "it-" %))
(iterate inc 1)]
`(let [~it ~test] (if ~it ~then ~else
#'proteus/aif
proteus> (aif (get {:x {:y
There was some discussion a few days ago about how the lack of local
mutable variables were harming performance, or possibly elegance, I'm not
sure. Regardless, I fixed it: https://github.com/ztellman/proteus
Enjoy!
--
--
You received this message because you are subscribed to the Google
Gro
