These are chat archives for ramda/ramda

21st
Feb 2016
Hardy Jones
@joneshf
Feb 21 2016 02:32
@ashnur that's exactly where T shines, that we were talking about the other day. You'd be funcs.map(T(value))
@ashnur you should also be able to use R.call
R.call
Hardy Jones
@joneshf
Feb 21 2016 02:34
@ram-bot R.map(R.call(R.__, 32), [R.add(10), R.add('wat'), R.equals(3)])
ram-bot
@ram-bot
Feb 21 2016 02:34
[ [Function: f1], [Function: f1], [Function: f1] ]
Hardy Jones
@joneshf
Feb 21 2016 02:34
well apparently not
Scott Sauyet
@CrossEye
Feb 21 2016 02:40
@ram-bot R.juxt([R.add(10), R.add('wat'), R.equals(3)])(32)
ram-bot
@ram-bot
Feb 21 2016 02:40
[ 42, 'wat32', false ]
GÁBOR Áron Zsolt
@ashnur
Feb 21 2016 02:40
@joneshf where is this T then?
juxt.. where is this name coming from? :D
Scott Sauyet
@CrossEye
Feb 21 2016 02:42
@ram-bot R.map(R.apply(R.__, [32]), [R.add(10), R.add('wat'), R.equals(3)])
ram-bot
@ram-bot
Feb 21 2016 02:42
[ 42, 'wat32', false ]
GÁBOR Áron Zsolt
@ashnur
Feb 21 2016 02:44
yeah, this last one is the one i could've come up with, but this is obviously worse than just writing a lambda
juxt is nice, i just with i knew why this is the name
Scott Sauyet
@CrossEye
Feb 21 2016 02:45
Stolen from clojure, I believe. No real idea. Short for "juxtapose"? Even then, I don't know why.
There's a problem with trying to partially apply call, because of its variadic nature.
GÁBOR Áron Zsolt
@ashnur
Feb 21 2016 02:50
yeah, .call is not good most of the times.
i tried to avoid it even before i started using ramda
Hardy Jones
@joneshf
Feb 21 2016 02:51
hmm, what'd I do wrong there?
Scott Sauyet
@CrossEye
Feb 21 2016 02:51
Funny, I use Function.prototype.call often. But this is one of the few remaining variadic functions in Ramda, and I think we really need to fix that. The trouble is... how?
Hardy Jones
@joneshf
Feb 21 2016 02:51
@ram-bot R.map(R.call(R.__)(32), [R.add(10), R.add('wat'), R.equals(3)])
ram-bot
@ram-bot
Feb 21 2016 02:51
TypeError: fn.apply is not a function
Hardy Jones
@joneshf
Feb 21 2016 02:51
buh
who knows what's going on there
Scott Sauyet
@CrossEye
Feb 21 2016 02:52
What I'm discussing. R.call is variadic. We only really know about the function parameter. Partial application/currying don't play well with it.
Hardy Jones
@joneshf
Feb 21 2016 02:52
I'd vote deprecation then removal
Scott Sauyet
@CrossEye
Feb 21 2016 02:53
Rather find a way to make it work. But the only thing I see would really make it a synonym of R.apply, so perhaps you're right.
Hardy Jones
@joneshf
Feb 21 2016 02:54
Apparently, I don't even know how to use R.call :)
I totally thought it worked differently
Scott Sauyet
@CrossEye
Feb 21 2016 02:55
@ram-bot R.call(R.add(10), 32)
ram-bot
@ram-bot
Feb 21 2016 02:55
42
Scott Sauyet
@CrossEye
Feb 21 2016 02:56
@ram-bot R.call(R.add, 4, 8)
ram-bot
@ram-bot
Feb 21 2016 02:56
12
Hardy Jones
@joneshf
Feb 21 2016 02:57
hmm, howcome it doesn't work for partial application then?
Scott Sauyet
@CrossEye
Feb 21 2016 02:58
but R.call(R.__, 32)(R.add(10)) fails to work as expected.
Haven't dug into it, but our partial application probably needs to know the arity of the function, and call is variadic. Anything > 1 is allowable.
Hardy Jones
@joneshf
Feb 21 2016 02:59
@ram-bot const T = R.curry((x, f) => f(x)); R.map(T(32), [R.add(10), R.add('wat'), R.equals(3)])
ram-bot
@ram-bot
Feb 21 2016 02:59
TypeError: fn is not a function
Hardy Jones
@joneshf
Feb 21 2016 02:59
ugh
joneshf @joneshf gives up
Scott Sauyet
@CrossEye
Feb 21 2016 03:01
oh, worse than I thought. Hmmm.
@ram-bot const X = R.curry((x, f) => f(x)); R.map(X(32), [R.add(10), R.add('wat'), R.equals(3)])
ram-bot
@ram-bot
Feb 21 2016 03:03
[ 42, 'wat32', false ]
Scott Sauyet
@CrossEye
Feb 21 2016 03:04
Think there's a slight problem with ram-bot. It probably declares the R variables as const in its environment. You tried to redefine R.T
We have the same issue in the REPL.
@ram-bot const X = curry((x, f) => f(x)); map(X(32), [add(10), add('wat'), equals(3)])
ram-bot
@ram-bot
Feb 21 2016 03:05
[ 42, 'wat32', false ]
Scott Sauyet
@CrossEye
Feb 21 2016 03:08
@raine: Is it worth reconsidering this? I noticed it first in the REPL, when I tried to define my own max function.
flip should also work.
@ram-bot: map(flip(call)(32), [add(10), add('wat'), equals(3)])
ram-bot
@ram-bot
Feb 21 2016 03:10
[ 42, 'wat32', false ]
David Chambers
@davidchambers
Feb 21 2016 03:29
I agree that R.call should be removed. It has proven itself unworthy.
Scott Sauyet
@CrossEye
Feb 21 2016 03:31
One other point in favor of removing it: if the best example we can find for using it is the one in the docs, then it's definitely not worth keeping.
GÁBOR Áron Zsolt
@ashnur
Feb 21 2016 04:03
i don't know when is such a thing useful. i knew console.log is variadic and i use this feature of it a lot, but otherwise, i am curious where else would people use it
Hardy Jones
@joneshf
Feb 21 2016 07:22
@CrossEye would it count for an additional point if I log in from another account? :)
Raine Virta
@raine
Feb 21 2016 08:57
@ram-bot T = 'foo'; T
ram-bot
@ram-bot
Feb 21 2016 08:57
'foo'
Raine Virta
@raine
Feb 21 2016 08:57
@ram-bot const T = 'foo'; T
ram-bot
@ram-bot
Feb 21 2016 08:57
[Function]
Raine Virta
@raine
Feb 21 2016 08:57
@ram-bot var T = 'foo'; T
ram-bot
@ram-bot
Feb 21 2016 08:57
'foo'
Hardy Jones
@joneshf
Feb 21 2016 08:59
@ram-bot const T = 'foo'; T()
@ram-bot const T = 'foo'; T()
ram-bot
@ram-bot
Feb 21 2016 08:59
true
Hardy Jones
@joneshf
Feb 21 2016 08:59
@ram-bot var T = 'foo'; T()
ram-bot
@ram-bot
Feb 21 2016 08:59
TypeError: T is not a function
Hardy Jones
@joneshf
Feb 21 2016 09:00
@ram-bot const T = 'foo'; R.T()
ram-bot
@ram-bot
Feb 21 2016 09:00
true
Hardy Jones
@joneshf
Feb 21 2016 09:00
@ram-bot var T = 'foo'; R.T()
ram-bot
@ram-bot
Feb 21 2016 09:00
true
Raine Virta
@raine
Feb 21 2016 09:04
does it seem like a bug in vm?
Richard Seldon
@arcseldon
Feb 21 2016 15:53
Hi. I am looking at the ramda fantasy types atm, think i understand most of it now, and how it relates to Ramda api functions. Got a question on how to unnest Monads of different types. So for example:
const nestedIceCream = Maybe(Maybe('Ice cream'));
const res1 = R.chain(R.identity, nestedIceCream);
console.log(res1);
const res2 = R.unnest(nestedIceCream);
console.log(res2);
In both cases, this has reduced the nesting by one level
I was looking for a function named chain / mjoin, but unnest seems to be the equivalent here.
But if I have say IO(Maybe('Ice Cream')) what are my options? Would I use R.lens and define some kind of double mapping ?
Aldwin Vlasblom
@Avaq
Feb 21 2016 16:16

@arcseldon R.unnest is just an alias to R.chain(R.identity). When you're chaining, you're basically merging the return value of your transformation with its parent container, and this is only possible when they're of the same type. Type IO wouldn't know how to mimic the specialized properties of type Maybe, it only knows how to absorb other IOs. Basically you'll have to map(map(f)) over your nested types.

Sometimes you're only using the innermost type for a while, and you could map(pipe(map(f), chain(g), ap(x))); using a pipe to reduce the amount of times you have to map over the outer most type.

The only way to actually reduce the nesting level involves type-casting. For example:

const maybeToFuture = err => m => m.isNothing() ? Future.reject(err) : Future.of(m.getOrElse());

Future.of(Maybe.of(1)).chain(maybeToFuture('We found Nothing'))
//> Future[String, Number]
Hardy Jones
@joneshf
Feb 21 2016 16:21
That's not type casting. You're implementing a fold
Richard Seldon
@arcseldon
Feb 21 2016 16:22
@Avaq - thank you for the explanation. Got it. I was aware chain / mjoin would only work on same types, but i hadn't considered the final suggestion. Just seen comment from @joneshf too.
so we would need some kind of decision making logic to unravel one level of nesting (transform it to the other type for example, which could then be flattened)
Hardy Jones
@joneshf
Feb 21 2016 16:25
@Avaq Though in this case, it's closer to a natural transformation...
@arcseldon Many of the suggestions are going to depend on your actual use case.
@arcseldon there are certain things you can do easily with some data types, that you can't do at all with others.
@arcseldon like, if you're only ever going to be maping or aping, and you know your data types up front. You might have an easier time if you create your values with Compose and let things happen naturally.
Hardy Jones
@joneshf
Feb 21 2016 16:30
@arcseldon but if you need more power, like chain. Or if youre going to cchange data types frequently, it probably doesn't make sense to bring in Compose.
Scott Sauyet
@CrossEye
Feb 21 2016 16:32
A big welcome to the newest member of the Ramda core team, @asaf-romano!
Richard Seldon
@arcseldon
Feb 21 2016 16:33
@asaf-romano - congrats !
@joneshf - thanks for this info too. All v.helpful.
Hardy Jones
@joneshf
Feb 21 2016 16:35
@arcseldon if you're using Future at the top of your stack of data types, you can't even use an abstraction like a monad transformer to cclean things up. Whereas, if something like Reader or Either is at the top, you could clean it up with a transformer.
@asaf-romano :+1:
Asaf
@asaf-romano
Feb 21 2016 16:36
Thanks ")
:)
Richard Seldon
@arcseldon
Feb 21 2016 16:38
at risk of asking stupid questions here... are there any natural transformers or otherwise provided out of the box.. or is each so dependent on the context of what you are trying to achieve that the onus is always on the user to create one as needed?
was wondering if patterns have emerged and been captured as helper fns etc
Richard Seldon
@arcseldon
Feb 21 2016 16:47
" if you're only ever going to be maping or aping, and you know your data types up front. You might have an easier time if you create your values with Compose and let things happen naturally" - think i shall stick to this as much as possible to keep things easy..
Hardy Jones
@joneshf
Feb 21 2016 16:57
There are some pretty common ones, but I don't know if they're sitting in a library anywhere
@ram-bot const maybeToList = S.maybe([], R.of); maybeToList(S.Nothing())
ram-bot
@ram-bot
Feb 21 2016 16:59
[]
Hardy Jones
@joneshf
Feb 21 2016 17:00
@ram-bot const maybeToList = S.maybe([], R.of); maybeToList(S.Just(3))
erm, did I kill it?
@ram-bot const maybeToList = S.maybe([], R.of); maybeToList(S.Nothing())
ram-bot
@ram-bot
Feb 21 2016 17:00
[]
Hardy Jones
@joneshf
Feb 21 2016 17:00
wait, what?
@ram-bot const maybeToList = S.maybe([], R.of); maybeToList(S.Maybe.of(3))
ram-bot
@ram-bot
Feb 21 2016 17:01
[ 3 ]
Hardy Jones
@joneshf
Feb 21 2016 17:01
k, that's wierd
@ram-bot const eitherToMaybe = S.either(S.K(S.Nothing()), S.Maybe.of); eitherToMaybe(S.left(12))
ram-bot
@ram-bot
Feb 21 2016 17:03
TypeError: S.left is not a function
Hardy Jones
@joneshf
Feb 21 2016 17:04
ooops
@ram-bot const eitherToMaybe = S.either(S.K(S.Nothing()), S.Maybe.of); eitherToMaybe(S.Left(12))
ram-bot
@ram-bot
Feb 21 2016 17:04
Nothing()
Hardy Jones
@joneshf
Feb 21 2016 17:04
@ram-bot const eitherToMaybe = S.either(S.K(S.Nothing()), S.Maybe.of); eitherToMaybe(S.Right('yep'))
ram-bot
@ram-bot
Feb 21 2016 17:04
Just("yep")
Hardy Jones
@joneshf
Feb 21 2016 17:04
and so on
though, actually, that's not really a natural transformation
eh, well maybe it is
Either a ~> Maybe
Richard Seldon
@arcseldon
Feb 21 2016 17:05
@joneshf - thank you again. got some sense of what's involved now. cheers for the examples
2 am here in JP, so laters.
Hardy Jones
@joneshf
Feb 21 2016 17:06
@arcseldon np
Oh, I guess S.maybeToEither already exists
erm
S.maybeToEither
k
The bot doesn't yet generate links to Sanctuary functions.
GÁBOR Áron Zsolt
@ashnur
Feb 21 2016 23:17
how would you write this differently? https://gist.github.com/ashnur/eb5679a187e5476837e6