These are chat archives for ramda/ramda

19th
Jun 2015
Jethro Larson
@jethrolarson
Jun 19 2015 00:00
Yeah. There doesn't seem to be an obvious way to do the sigs. Which is why I see it done a bunch of different ways
Hardy Jones
@joneshf
Jun 19 2015 00:00
List may be a Monad sure, but Future can't be, since the kind isn't correct. Future a can be a Monad though.
the difference is subtle but non-trivial
Jethro Larson
@jethrolarson
Jun 19 2015 00:01
Well does that really derail my original point?
Hardy Jones
@joneshf
Jun 19 2015 00:02
As I interpreted it, you said that a, b are in the monad.
but the a cannot change.
whereas the b is free to vary
Jethro Larson
@jethrolarson
Jun 19 2015 00:02
That's not true
Hardy Jones
@joneshf
Jun 19 2015 00:03
which part?
Jethro Larson
@jethrolarson
Jun 19 2015 00:03
a and b are functions
Hardy Jones
@joneshf
Jun 19 2015 00:03
they might be
they might not be
Jethro Larson
@jethrolarson
Jun 19 2015 00:04
I don't see how a and b are different. The only difference I see is that a == failure function and b == success function
but I'll think on it for a mo
Scott Christopher
@scott-christopher
Jun 19 2015 00:06
Perhaps think of a and b as the types that Promise doesn’t know about.
Promise knows that both arguments are functions, but it doesn’t know the type that they return.
So if you see a Promise a b (or Promise[a, b]) you know that the error case will produce an a, and the success case will produce a b.
Jethro Larson
@jethrolarson
Jun 19 2015 00:10
Okay. So the distinction is that List[a] is known now and Future[a, b] is indeterminate?
Scott Christopher
@scott-christopher
Jun 19 2015 00:11
Or have I completely missed the point of this conversation, whereby you’re talking about the signature of the Future constructor? :D
Jethro Larson
@jethrolarson
Jun 19 2015 00:12
Really talking about how to write sigs for types for Ramda-fantasy stuffs
Scott Christopher
@scott-christopher
Jun 19 2015 00:12
Ok
Jethro Larson
@jethrolarson
Jun 19 2015 00:12
but I accept any derailing that deepens my understanding
Hardy Jones
@joneshf
Jun 19 2015 00:13
I guess it depends on your definition of indeterminate. It is known deterministically that it will be a future value of one of (and only one of) a or b. But it is not known which one.
Jethro Larson
@jethrolarson
Jun 19 2015 00:14
neither a nor b exist until fork though
Scott Christopher
@scott-christopher
Jun 19 2015 00:14
correct
Think of a and b as variables at a type level
Hardy Jones
@joneshf
Jun 19 2015 00:15
And to bring it back around, the monadic interface cannot talk about changing the a.
If it happens to be an a, in the future.
Jethro Larson
@jethrolarson
Jun 19 2015 00:16
I guess what's in the future is really the function from [a,b] -> either a or b
Hardy Jones
@joneshf
Jun 19 2015 00:17
but the monadic interface can change the b all day.
Jethro Larson
@jethrolarson
Jun 19 2015 00:18
I don't get that
Hardy Jones
@joneshf
Jun 19 2015 00:18
okay
what does map do?
for Future
Jethro Larson
@jethrolarson
Jun 19 2015 00:19
puts a function on the eventual success value
I guess I see
Typically there's no interface for the failure case
without bimap or chainReject
Hardy Jones
@joneshf
Jun 19 2015 00:20
right
Jethro Larson
@jethrolarson
Jun 19 2015 00:20
I just see that as stuff that should be implemented though
Hardy Jones
@joneshf
Jun 19 2015 00:20
so the Bifunctor interface can talk about changing as and bs all day.
but the Monad interface cant
Jethro Larson
@jethrolarson
Jun 19 2015 00:21
Ok I keep forgetting that these are mixins
:)
Hardy Jones
@joneshf
Jun 19 2015 00:21
yeah, it's tough to work with this stuff entirely in your head
Jethro Larson
@jethrolarson
Jun 19 2015 00:22
Yeah, the only progress I make is by looking at the implementations and examples, really. Reading descriptions mostly just makes my head spin
Scott Christopher
@scott-christopher
Jun 19 2015 00:25
If you have an f that conceptually has the type Future Int String (where a = Int and b = String), you can call f.chain(someFn).chain(nextFn).chain(andSoOnFn) and the error case will always produce an Int in this case, but the functions passed to each chain could change the b from String to anything else along the way.
So the Monad interface (chain) can only change the b type variable in Promise.
Jethro Larson
@jethrolarson
Jun 19 2015 00:27
Yeah. That's why I have this PR: ramda/ramda-fantasy#54
Maybe it's not Math-y but it's useful so if there's a better word for what I'm trying to do I welcome it
Scott Christopher
@scott-christopher
Jun 19 2015 00:35
That seems legit. Perhaps another name to consider would be recover?
Jethro Larson
@jethrolarson
Jun 19 2015 00:36
not sure how discoverable that is
does that come from somewhere else?
I don't like .orElse from folktale
I only found it by looking at the sigs
I suppose there could alternately be a bichain
which I would pronounce bitchin' of course
Scott Christopher
@scott-christopher
Jun 19 2015 00:39
:)
Jethro Larson
@jethrolarson
Jun 19 2015 00:40
I don't even know if Bimonad is a thing
Scott Christopher
@scott-christopher
Jun 19 2015 00:43
scalaz’s Task has handleWith for your chainReject and handle for an equivalent mapReject.
Jethro Larson
@jethrolarson
Jun 19 2015 00:44
chain sound like a verb to me and in the failure case you're still doing the same thing, just on a different path
It makes sense to me to make the names similar
Scott Christopher
@scott-christopher
Jun 19 2015 00:47
I think the current naming is fine. I was just throwing out other suggestions.
Jethro Larson
@jethrolarson
Jun 19 2015 00:48
sure
I guess "chain" wont change since fantasy-land has stablized
Scott Christopher
@scott-christopher
Jun 19 2015 00:49
Well bind is already claimed by Function
Jethro Larson
@jethrolarson
Jun 19 2015 00:50
is chain essentially flatmap?
Scott Christopher
@scott-christopher
Jun 19 2015 00:51
yep
Jethro Larson
@jethrolarson
Jun 19 2015 00:53
I don't suppose anyone here is in Seattle and would want to get a beer sometime
Scott Christopher
@scott-christopher
Jun 19 2015 00:53
While I’d love to, it’s a bit of a way from Sydney :)
Jethro Larson
@jethrolarson
Jun 19 2015 00:54
Yeah, I'm seeing quite the international representation in audience
Michael Hurley
@buzzdecafe
Jun 19 2015 00:55
orElse seems threatening
Jethro Larson
@jethrolarson
Jun 19 2015 00:55
unchain
chainBad
chainBad sounds way too cool
Michael Hurley
@buzzdecafe
Jun 19 2015 00:56
chainOfFools?
Scott Christopher
@scott-christopher
Jun 19 2015 00:56
weakestLink
Jethro Larson
@jethrolarson
Jun 19 2015 01:08
yeah, chainReject is best I got.
Jethro Larson
@jethrolarson
Jun 19 2015 01:15
var fetchJSON = fetch.chain(parseJSON); is probably my favorite part of the future example. I love it when the function names match what they do.
Scott Sauyet
@CrossEye
Jun 19 2015 01:28
Beautiful stuff, @jethrolarson!
Jethro Larson
@jethrolarson
Jun 19 2015 02:07
EitherToFuture = function(eith){
  return new Future(eith.bimap);
};
brilliant, obvious, or retarded?
Jethro Larson
@jethrolarson
Jun 19 2015 02:18
I guess the future still has either inside... so I could bimap to get the value out and eliminate the either
eitherToFuture = function(e){
  return new Future(e.bimap).bimap(R.prop('value'), R.prop('value'));
};
Scott Sauyet
@CrossEye
Jun 19 2015 02:25
Feels as though there should be something more elegant.
Hardy Jones
@joneshf
Jun 19 2015 02:40
var eitherToFuture = function(e) {
  return e.either(Future.reject)(Future.of);
};
of course, you need an either function for that...
Jethro Larson
@jethrolarson
Jun 19 2015 02:56
Fantasy Either doesn't have a way to check which value you have. I guess you could instanceof Either.Right. Not elegant tho
Jethro Larson
@jethrolarson
Jun 19 2015 03:02
I guess the cool factor is being able to myfuture.chain(eitherToFuture) and keep things flattened
Hardy Jones
@joneshf
Jun 19 2015 03:55
either is derivable from isLeft which is derivable from bimap, in a sort of hacky way.
asaf-romano @asaf-romano wonders if there's some built-in shortcut for zipWith(call)
Asaf
@asaf-romano
Jun 19 2015 14:42
@svozza thanks for the info about stream. will try it soon.
looks promising.
although the highland documentation assumes lodash everywhere, advocating the chain syntax.
Jethro Larson
@jethrolarson
Jun 19 2015 17:30
anyone else annoyed that fantasy "chain" is not consistent with the practice of chaining functions jQuery-style?
Raine Virta
@raine
Jun 19 2015 17:37
what do you mean?
Jethro Larson
@jethrolarson
Jun 19 2015 17:39
I mean like "chain" syntax is a more general concept than Either.Right(1).chain(...
$('a').click().remove().find('span').hide().end().carousel();
Raine Virta
@raine
Jun 19 2015 17:41
yeah well it's entirely different concept
Hardy Jones
@joneshf
Jun 19 2015 18:13
nah, that's backwards
fluent interface is a more specific concept than Chain
the . is just a syntactic sugar for chain.
Jethro Larson
@jethrolarson
Jun 19 2015 18:24
okay I guess it's apples and oranges. Which is really my point. Yet another word like bind or map that's doing double or triple duty
Stefano Vozza
@svozza
Jun 19 2015 18:31

although the highland documentation assumes lodash everywhere, advocating the chain syntax.

Yes, that seems to be the syntax most of our users are comfortable with but everything you can do with the chaining syntax you can do with the hl.<operator> syntax. i keep meaning to give an example for both styles for every operator in the docs but I've not had a chance.

Scott Sauyet
@CrossEye
Jun 19 2015 18:43
>>= is out of the question, and bind was already spoken for. I'm not a big fan of chain, but the only real alternative seems to be flatMap
Jethro Larson
@jethrolarson
Jun 19 2015 19:29
thru / through? This talk refers to it as shove https://www.youtube.com/watch?v=ZhuHCtR3xq8
Jethro Larson
@jethrolarson
Jun 19 2015 19:36
for the record, I'm not really proposing we change it. I just think 'chain' makes it a little more difficult for newbies.
Joseph Abrahamson
@tel
Jun 19 2015 19:38
@jethrolarson Can't you distinguish between left and right very directly with fantasyland? You can use cata or fold
Jethro Larson
@jethrolarson
Jun 19 2015 19:38
I don't follow
Jethro Larson
@jethrolarson
Jun 19 2015 20:04
Is the difference between Reader and Future just that Future handles failure cases?
Hardy Jones
@joneshf
Jun 19 2015 20:45
@jethrolarson I'm not sure I understand the distinction you're trying to make between fluent interface and Chain
Hardy Jones
@joneshf
Jun 19 2015 20:57
Also, Reader and Future are different ideas. Reader is just Function codified as another data type.
Hardy Jones
@joneshf
Jun 19 2015 21:09
Oh hi @tel
Scott Sauyet
@CrossEye
Jun 19 2015 21:11
I haven't played much with Reader but my, er, reading makes it seem like a function closed over some lexical scope. Is that close?
Something that might be used to look up data from an app configuration object loaded at startup might use a Reader, for instance.
Arve Knudsen
@aknuds1
Jun 19 2015 22:25
Why is forEachIndexed deprecated?
Michael Hurley
@buzzdecafe
Jun 19 2015 23:14
because addIndex makes it redundant
Arve Knudsen
@aknuds1
Jun 19 2015 23:36
Ah
Thanks @buzzdecafe