These are chat archives for ramda/ramda

18th
Jul 2017
Jason Shin
@JasonShin
Jul 18 2017 00:27
@skatcat31 Do you mean pipe aka flow?
I'm not against anything but it seems like lodash/fp doesn't support future chaining
I mean this one. You said you didn't like that the other compose was left -> right
also if that's the problem, have you tried fluture?
Robert Mennell
@skatcat31
Jul 18 2017 00:35
That moment when you've hit insanity and decide to rewrite pipe and curry in pure ES and do it in 10 or less lines...
Jason Shin
@JasonShin
Jul 18 2017 00:36
lol
I think you still need "chain" method with fluture right
I just love to compose functions in right -> left
it's just more logical
(f(g(x)))
Robert Mennell
@skatcat31
Jul 18 2017 00:38
more logical is purely a point of view. Many people think left to right, others right to left. A good example: var lessthan3 = gt(3)
Jason Shin
@JasonShin
Jul 18 2017 00:38
that's still right to left isn't it? You are passing in an argument from right (fp noob here)
Robert Mennell
@skatcat31
Jul 18 2017 00:39
@JasonShin with fluture or future you're going to need a wrapper function for chain or map because the object returned in a Future(return) which means any further operations on it will require calling the chain or map functionality since a Future is a type construct, not a pure value
and no, gt(3,4) == false // 3>4
many people however think right -> left should be the way to go, but lets look at an API block: new Promise(() => 1).then( num => num + 2).then(console.log) == pipe(identitiy, add(2), console.log)
Jason Shin
@JasonShin
Jul 18 2017 00:54
yeah but still
I think right to left makes more sense when it comes to composition
it's literally like
(func3, func2, func1) <- give inputs
and it just flows through in that order
if you do left to right, you will have to do a lot of eye balling when you are debugging your code
Rick Medina
@rickmed
Jul 18 2017 02:13
I find it the other way around, compose for me breaks left-down reading flow
Ryan Zeigler
@rzeigler
Jul 18 2017 02:17
so, I think of it as this
compose maintains ordering
i.e. compose(f, g, h)(v) === f(g(h(v))
but often times pipe feels more natural
James
@aretecode
Jul 18 2017 11:40

https://github.com/ramda/ramda/blob/master/src/internal/_arity.js#L11

why are the arguments there? performance? having .length? any comments about it somewhere to read?

Gabe Johnson
@gabejohnson
Jul 18 2017 13:28
Maybe built-in for JS. Yea or nay?
James Forbes
@JAForbes
Jul 18 2017 13:28
yea
Philipp Wille
@Yord
Jul 18 2017 13:29
Not sure. At the end it may be the same as with Promise: We use fluture instead ;)
Michael Rosata
@mrosata
Jul 18 2017 13:32
@gabejohnson lol, I was just thinking something similar to @Yord, it would be great to have Maybe native. It would be a shame to have it be something that wasn't done properly
Gabe Johnson
@gabejohnson
Jul 18 2017 13:33
@mrosata @Yord that's why this community would have to drive the effort
Michael Rosata
@mrosata
Jul 18 2017 13:36
@gabejohnson I will come for the ride. I'm going to follow in sanctuary room
Gabe Johnson
@gabejohnson
Jul 18 2017 13:36
:thumbsup:
Philipp Wille
@Yord
Jul 18 2017 13:58
@gabejohnson I see where you come from. Good idea then!
Brad Compton (he/him)
@Bradcomp
Jul 18 2017 15:29
@aretecode I don't know of any other way to get function.length to be correct.
Gabe Johnson
@gabejohnson
Jul 18 2017 15:32
Discussion of Maybe expanded in the Sanctuary room

Hello :)

I am trying to create a 'filterAccum' method, which is going to work exactly like 'filter', expect it will have an accumulator method to transform the data during each iteration, before using a filter on the modified data.

My problem is I have to make an exception (see the 'if' line in my code) to handle an array of numbers instead an array of string, because I am using mapAccum behind the scene, and the "acc" parameter of "mapAccum" should be 0 by default when operating on numbers, but [] when operating on anything else.

How can I improve this code to avoid making this exception ? (maybe using something else than mapAccum)

I provided an example that works with Integers and one with strings
Denis Stoyanov
@xgrommx
Jul 18 2017 16:22
@JulienBonnin-ABTasty reduce + predicate?
Julien Bonnin
@JulienBonnin-ABTasty
Jul 18 2017 16:27
Do you mean using a predicate for the accumulator value of the reduce method ?
Philipp Wille
@Yord
Jul 18 2017 17:52

@JulienBonnin-ABTasty To elaborate on what @xgrommx said, something like:

const filterAccum = curry(
  (p, fn, acc, list) => reduce((a, v) => p(v) ? fn(a, v) : a, acc, list)
)

That would allow you to:

filterAccum(n => n % 2 === 1, (...n) => R.sum(n), 0, [5, 10, 15]) // 20

const strings = filterAccum(n => n.length % 2 === 1, (a, b) => a + b, '')
strings(['aweso', 'me!', 'cannot see this!'])
Philipp Wille
@Yord
Jul 18 2017 18:02
(in this implementation you would pass an explicit starting value of course...)
Julien Bonnin
@JulienBonnin-ABTasty
Jul 18 2017 20:19
ok :) Thank you, I thinking I could go without giving the starting value but it seems like a good way to do it :thumbsup: (I just need to modify it a little so it returns a list instead of the first matching value)
James
@aretecode
Jul 18 2017 20:48
@Yord so it's just for the function.length?
Julien Bonnin
@JulienBonnin-ABTasty
Jul 18 2017 20:58
I ended up doing something simpler but more flexible
(No need to specify the initial value, it will be the first in the provided array, so no type exception either, and it can be piped with filter/find/other if need to)