Happen to be playing with wisp a lot more this past two weeks, still loving it. Two functions (well more probably) I found missing and use a lot and I was wondering if there was a reason for excluding them.
Of these 3 I know they can be 100% copy/pasted and work in wisp:
partial
comp
complement
update: I added additional implementations of:
select-keys
get-in
take-while
drop-while
split-at
spread
list*
juxt (although not the same without keyword fns, I did a little patch though but since it diverts from the actual wisp convention (keywords are not functions), I do not think this is a great idea) for the rest np on actual fns ofc.
not=
mapcat
treeseq
Although all of them are exact copies (one or two require e.g. RT java lib or some other object/fn unavailable). But using simple loop ... recur variations most of its behavior can be emulated perfectly fine.
Of macro's, I recon the (comment ...) would have been nice-to-have as readily available from wisp core. But I'm guessing you want to try and keep that number of out-of-the-box fn's and macro's to a low threshold, am I correct?
If wanted, I could do a pull request augmenting those.
Hey Gozala,
Happen to be playing with wisp a lot more this past two weeks, still loving it. Two functions (well more probably) I found missing and use a lot and I was wondering if there was a reason for excluding them.
Of these 3 I know they can be 100% copy/pasted and work in wisp:
partial
comp
complement
update: I added additional implementations of:
select-keys
get-in
take-while
drop-while
split-at
spread
list*
juxt
(although not the same without keyword fns, I did a little patch though but since it diverts from the actual wisp convention (keywords are not functions), I do not think this is a great idea) for the rest np on actual fns ofc.not=
mapcat
treeseq
Although all of them are exact copies (one or two require e.g. RT java lib or some other object/fn unavailable). But using simple
loop ... recur
variations most of its behavior can be emulated perfectly fine.Of macro's, I recon the
(comment ...)
would have been nice-to-have as readily available from wisp core. But I'm guessing you want to try and keep that number of out-of-the-box fn's and macro's to a low threshold, am I correct?If wanted, I could do a pull request augmenting those.