specter

Latest version: 1.1.3
razum2um 2018-03-09T15:18:41.000573Z

is there a way to express this better?

=> (transform [(if-path [#(contains? % :loc)] [:loc ALL])] inc {:x 1})
{:x 1}
=> (transform [(if-path [#(contains? % :loc)] [:loc ALL])] inc {:loc [1]})
{:loc [2]}
don’t want extra key after simple
=> (transform [:loc ALL] inc {:x 1})
{:x 1, :loc nil}

nathanmarz 2018-03-09T15:27:11.000702Z

@razum2um

(transform [(must :loc) ALL] inc data)

❤️ 1
razum2um 2018-03-09T15:36:19.000570Z

thanks!

razum2um 2018-03-09T15:38:29.000525Z

@nathanmarz btw, I had an idea about the vector as a forth program, did you think about this?

nathanmarz 2018-03-09T15:58:15.000379Z

@razum2um no, what do you mean?

razum2um 2018-03-09T16:01:15.000414Z

currently the library api interface looks convenient but adhoc, I feel there shoud be case out there which cannot fit into vector. I thought we could imagine the traversal as “bytecodes” steps to the lib (interpretator)

razum2um 2018-03-09T16:03:03.000347Z

I understand implementing VM for data traversal is not easy 😅 but just wanted to share this

razum2um 2018-03-09T16:03:43.000442Z

just on the spot: e.g. in this way we could even allow some recursion steps in traversal

razum2um 2018-03-09T16:06:53.000587Z

example2: my request above in this approach could look like (transform [:loc >nil? <STOP ALL] inc {:x 1}) where >nil? puts on stack if loc return value is nit <STOP pops and shortcuts path if last val was true

nathanmarz 2018-03-09T16:07:47.000320Z

that would increase the complexity of specter by 1000x

1
razum2um 2018-03-09T16:07:59.000446Z

yeah 🙂

nathanmarz 2018-03-09T16:08:10.000853Z

specter is not a language, it's just an interface and an efficient method for composing them

nathanmarz 2018-03-09T16:08:43.000367Z

there's no known use cases it doesn't handle, so there's no reason to do something like that

razum2um 2018-03-09T16:08:45.000313Z

don’t push you, just wanted to hear your thoughts

razum2um 2018-03-09T16:09:10.000554Z

thanks for your efforts btw 👍

razum2um 2018-03-09T16:09:49.000135Z

is it ok if I’ll PR to the readme.md with must example?

nathanmarz 2018-03-09T16:10:31.000648Z

sure thing

nathanmarz 2018-03-09T16:11:16.000076Z

not sure what to do with the readme, it's kind of just a random exploration of different kinds of manipulations

nathanmarz 2018-03-09T16:12:22.000125Z

I don't think making that section longer than it already is will improve things

nathanmarz 2018-03-09T16:12:31.000383Z

the wiki is pretty good nowadays

nathanmarz 2018-03-09T16:12:36.000002Z

so I just point people there

nathanmarz 2018-03-09T16:13:09.000768Z

and to answer your question about recursion, see https://github.com/nathanmarz/specter/wiki/Using-Specter-Recursively

👍 1
razum2um 2018-03-09T16:24:23.000744Z

hm, yes, I think now it’s quite too special example for readme.. but here is the point (from wiki) > Note that must stops navigation I think there should be a list with such “stopping” things, wdyt?

razum2um 2018-03-09T16:28:15.000158Z

still, here you are https://github.com/nathanmarz/specter/pull/249

razum2um 2018-03-09T16:31:50.000372Z

I think we have ~300 people here and readme should represent most common used cases. e.g. in same format as in clojuredocs (crowd-examples, maybe on same engine, afair it’s oss)

nathanmarz 2018-03-09T16:44:59.000172Z

@razum2um this is the categorization I use when thinking of navigators: https://github.com/nathanmarz/specter/wiki/Cheat-Sheet

razum2um 2018-03-09T16:46:05.000275Z

yeah, saw it. is there any other stopping word like must?

nathanmarz 2018-03-09T16:46:48.000497Z

ALL, MAP-KEYS, MAP-VALS will stop if there's nothing in the collection

nathanmarz 2018-03-09T16:46:51.000770Z

STOP explicitly stops

nathanmarz 2018-03-09T16:46:59.000737Z

terminal navigators explicitly stop

nathanmarz 2018-03-09T16:47:27.000571Z

set-elem and map-key stop if the elem/key isn't there

razum2um 2018-03-09T16:47:32.000811Z

ok, thanks 👍

nathanmarz 2018-03-09T16:47:51.000257Z

FIRST/`LAST` stop if the sequence is empty