These are chat archives for ramda/ramda

2nd
May 2015
Michael Hurley
@buzzdecafe
May 02 2015 11:42
that is to satisfy the linter i believe
Asaf
@asaf-romano
May 02 2015 12:00
Hey all, what is (if at all) the recommended way to do map+filter in one iteration?
in other words, can I replace es7's array-comprehensions without sacrificing performance too much
Raine Virta
@raine
May 02 2015 12:09
transducers?
Michael Hurley
@buzzdecafe
May 02 2015 12:19
:point_up:
Asaf
@asaf-romano
May 02 2015 12:45
I thought so, but the api looks a little too complicated for common operations.
unless I missed some variant of it.
Simon Friis Vindum
@paldepind
May 02 2015 12:46
@asaf-romano R.into? It's pretty simple.
Asaf
@asaf-romano
May 02 2015 12:47
map(prop("x"), filter(where({ y: 1 }), myList)) readability sets a very high standard
going to look at into
Raine Virta
@raine
May 02 2015 12:50
it would be something like compose(filter(where({ y: 1 })), map(prop('x'))
Asaf
@asaf-romano
May 02 2015 13:02
with the opposite args order I suppose
Raine Virta
@raine
May 02 2015 13:02
actually no

Acts as a transducer if a transformer is given in list position.

I'm trying to understand this. Where exactly is the transformer "given in list position" if R.filter is used as a transducer? Does it happen when R.transduce is used?

Asaf
@asaf-romano
May 02 2015 13:48
the order for your R.compose seems like pipe order to me
unless I'm confused again
in the non-lazy version I pass the result of filter to map
anyway, I found two shortcomings here:
Raine Virta
@raine
May 02 2015 13:51
order is inverse when composing a transducer
Asaf
@asaf-romano
May 02 2015 13:51
ah
1) when the transducer has multiple uses, this syntax is ok, but it seems a little too much when you inline
R.into([], R.transduce(R.compose....
it's not as declarative as the non-lazy version
2) For all common use case, you would reduce into an empty array
it seems that some declarative-sugar could help here
(thanks for the hint on the inverse order)
that library has seq, I haven't used equivalent in ramda but it would help
Asaf
@asaf-romano
May 02 2015 13:54
this is based on ramda/works with ramda/alternative to ramda?
ah
yes, wu.js also solves this well, I think. But apart lazy-ness handling I find ramda APIs simpler.
Raine Virta
@raine
May 02 2015 13:56
ramda doesn't have lazyness
Hardy Jones
@joneshf
May 02 2015 17:43
@asaf-romano a couple of more options are using reduce or using chain.
R.compose(R.map(f), R.filter(p)) === R.reduce(function(acc, x) { return p(x) ? R.append(f(x), acc) : acc; }, [])
R.compose(R.map(f), R.filter(p)) === R.chain(R.ifElse(p, R.compose(R.of, f), R.always([]))
Robin Lambertz
@roblabla
May 02 2015 22:25
Hey guys, I need something like R.all, but with the indexed passed to the predicate along with the element. Is there such a thing ?

I have done

R.reduceIndexed((acc, elem, idx, lst) => { return acc && elem === idx }, true);

but I'm fairly sure that's sub-optimal

Hardy Jones
@joneshf
May 02 2015 23:44
@roblabla that seems okay to me, what doesn't seem optimal?
Robin Lambertz
@roblabla
May 02 2015 23:45
R.all should stop as soon as it finds a "false" (I suppose), whereas this will continue until it ran on every node
ain't really a problem for me since my lists are fairly short though, just wanted to know if there was a better solution ^^
Hardy Jones
@joneshf
May 02 2015 23:47
does it actually do that?
oh, i guess it does
Hardy Jones
@joneshf
May 02 2015 23:56
well, you could alwys construct your own dealie
R.all(((x) => x[0] === x[1]), R.zip(xs, R.range(0, xs.length)))
wait, the zip would still enumerate all things.
maybe you can use a transducer for that, isn't that what they're made for?