Fork me on GitHub
Chris O’Donnell00:06:08

Note that if you're doing a transform, you'll lose the first element

(transform [(view rest) ALL] inc (range 5))
(2 3 4 5)


yeah I need the first element to stay intact


that was my first try but it doesn't quite work

Chris O’Donnell00:06:15

you don't need to call nextfn twice in your select

Chris O’Donnell00:06:42

you do need it in your transform*, though

Chris O’Donnell00:06:53

transform* also needs to perform nextfn on the passed in structure, and then reconstruct the original structure, replacing what you navigate to with the results of nextfn

Chris O’Donnell00:06:40

for example, the wiki example stores the result of (nextfn (nth structure n)) and then replaces the nth element of structure with it


isn't that what I was doing though?

Chris O’Donnell00:06:42

yep, you're right


ah, I needed to map next-fn over the (rest coll)


great, now it works

Chris O’Donnell00:06:29

no, that's not right

Chris O’Donnell00:06:44

I mean, you could do that if you want, but that's like doing [REST ALL]


yeah it was correct the firs time, but my own example useage was wrong


I updated the gist so that it now works on sets and maps as well, although obviously you probably wouldn't want to use it on thsoe


I think it'd be nice to have more selectors that mimic the bahavior of clojure.core functions (`TAKE`, DROP etc.)

Chris O’Donnell00:06:34

I did not know about empty

Chris O’Donnell00:06:44

some of those functions are in the works, I think (


this returns what I want, but I wonder if there's a way to write it using just one transform


the task is to read :foo and add it to each number of the REST of :bar


and then to lift the modified :bar to be the returned value from the outer transform


I think my vanilla Clojure version might be easier to read

Chris O’Donnell01:06:37

(transform [ALL (collect-one :foo) :bar REST ALL ALL] + data)


@codonnell: yeah that works except for it doesn't lift :bar up


but maybe (mapv :bar (transform [ALL (collect-one :foo) :bar REST ALL ALL] + data)) is the most readable

Chris O’Donnell01:06:05

alright, I'll take a closer look in a bit


I think that using collect-one with transform for the purpose of lifting an inner structure upwards is a bit verbose and doesn't feel so easily composable

Chris O’Donnell01:06:58

(transform [ALL (collect-one :foo) (view :bar) REST ALL ALL] + data)

Chris O’Donnell01:06:18

that does it, I think

Chris O’Donnell01:06:41

as for which is more readable, I'd say that's a matter of opinion

Chris O’Donnell01:06:49

probably has a lot to do with how familiar the reader is with specter


I did learn about view the other day so I should have been able to get that

Chris O’Donnell01:06:56

the fact that it's even possible to accomplish that transformation in one line of code is pretty absurd IMO


yeah definitely


if only I could think at the speed at which I can type that 😛


and adding one more level of complexity takes only a small tweak:


@severed-infinity: Def. a Cursive problem, not specter


You can get rid of almost all warning with the latest EAP version though


There you can tell Cursive that a macro is like a def, thus defining the symbols


And voila, you'll have full autocomplete for specter


Simply go into the specter (and macros) source file, hover over a (eg. devnav) usage and choose Resolve as ... def


@rauh Ah I am using the latest EAP but did not know about this


You have to go into the specter source


F12 for me, goto source or someting like that


Well, you can't do that on an unresolved symbol (yet) 🙂


so jump into specter source from maybe your (:require ...)