These are chat archives for ramda/ramda

31st
May 2016
David Chambers
@davidchambers
May 31 2016 05:38
@ram-bot
R.inc([42])
ram-bot
@ram-bot
May 31 2016 05:38
43
David Chambers
@davidchambers
May 31 2016 05:38
:wink2:
Aldwin Vlasblom
@Avaq
May 31 2016 07:22
@ram-bot [[[[[42]]]]] == 42
ram-bot
@ram-bot
May 31 2016 07:22
true
David Chambers
@davidchambers
May 31 2016 07:35
@ram-bot
[42] == [42]
ram-bot
@ram-bot
May 31 2016 07:35
false
David Chambers
@davidchambers
May 31 2016 07:36
@ram-bot
[42] == {toString: function() { return '42'; }}
ram-bot
@ram-bot
May 31 2016 07:36
false
Vladimir Starkov
@iamstarkov
May 31 2016 10:52
hej alla
how do you use .catch with R.pipeP?
Raine Virta
@raine
May 31 2016 10:53
hej
Denis Stoyanov
@xgrommx
May 31 2016 11:08
@ram-bot
Object.is([42], [42])
ram-bot
@ram-bot
May 31 2016 11:08
false
Denis Stoyanov
@xgrommx
May 31 2016 11:08
oh
Erwin Poeze
@donnut
May 31 2016 11:16
@iamstarkov
Vladimir Starkov
@iamstarkov
May 31 2016 11:17
@donnut sup?
Erwin Poeze
@donnut
May 31 2016 11:17
@iamstarkov
const getName = (name) => {
  return new Promise((fullfil, reject) => fullfil(name))
}
const splitName = (name) => {
  return new Promise((fullfil, reject) => fullfil(name.split(' ')))
}
var followersForUser = R.pipeP(getName, splitName);

followersForUser('Joe Doe').then(x => console.log(x))
@iamstarkov silly example of course, but does this answer your question?
Vladimir Starkov
@iamstarkov
May 31 2016 11:18
not really, but i appreciate your help
let me clarify
let say getName is IO operation (fs.readFile), splitName is processing file content
so, you dont want to catch IO errors, but want to decorate splitName errors in some way
let say add filename in which processing is broken
@donnut does it make sense?
Erwin Poeze
@donnut
May 31 2016 11:23
Yes, I didn't read your original question well enough
Vladimir Starkov
@iamstarkov
May 31 2016 11:26
so right before this decoration needed i used this contruction:
function esDeps(file) {
  return R.pipeP(toPromise,
    contract('file', String),
    readFile(R.__, 'utf8'),
    R.memoize(esDepsFromString)
  )(file);
}
and right now need to extend it to:
// parsing :: String :: String -> Promise [String]
const parsing = file => m => Promise.resolve(m)
  .then(R.memoize(esDepsFromString))
  .catch(_err => {
    const err = _err;
    err.message += ` in ${file}`;
    return Promise.reject(err);
  });

// esDeps :: String -> Promise [String]
function esDeps(file) {
  return R.pipeP(toPromise,
    contract('file', String),
    readFile(R.__, 'utf8'),
    parsing(file)
  )(file);
}
so, maybe there is a better way
Erwin Poeze
@donnut
May 31 2016 12:07
If I understand correctly, you want to intercept the error when esDepsFromString fails. In parsing I don't think catch is ever called.
Is that correct? I'm not an expert in this :worried:
Scott Sauyet
@CrossEye
May 31 2016 12:11
@LeonineKing1199: here's a possible realistic test case: A version of prop that takes a third, optional argument, which is a default if the value isn't found. This is the sort of variadic function common in JS that has been difficult to support.
Erwin Poeze
@donnut
May 31 2016 12:19
@iamstarkov @ram-bot
const getName = (name) => {
  return new Promise((fulfill, reject) => {
    if (!name) reject('no name given')
    else fulfill(name)
  })
}
const splitName = name => 
  new Promise((fullfil, reject) => {
    const chunks = name.split(' ')
    if (chunks.length > 2) reject('too many parts')
    else fullfil(chunks)
  })

var followersForUser = R.pipeP(getName, splitName);

followersForUser('Joe Doe Baz')
.then(x => console.log(x))
.catch(e => console.log("Error:  ", e))
@iamstarkov now both functions do some checking and can reject the solution. But, splitName is skipped if getName rejects, so I do not see how splitName could decorate the error because it is not called in that case.
andretshurotshka
@goodmind
May 31 2016 12:32
How to find all values matching predicate in list? not first, like R.find
Gabe Johnson
@gabejohnson
May 31 2016 12:33
@goodmind R.filter
LeonineKing1199
@LeonineKing1199
May 31 2016 15:23

@CrossEye Alright, yeah, we'll have to give it a shot. Though I'm not sure if that counts as a variadic because to me, a variadic function is one that's implemented in terms of arguments and not named variables (which is what a default is). Currying with default arguments might be interesting.

Would you mind describing the type of behavior you expect when currying functions with default arguments? I'm trying to imagine it now and it seems like something that me be different to different people.

Scott Sauyet
@CrossEye
May 31 2016 15:57
I was not thinking es6 default params, just something that was a default value for the prop function. Sorry for the confusion. Can't type examples well on my phone, but perhaps prop('favLib', {}); //=> undefined but prop('favLib', {}, 'Ramda');//=> 'Ramda'. Like many options objects in JS APIs.
LeonineKing1199
@LeonineKing1199
May 31 2016 16:02
Oh, I see. You mean something like this?
const f = (param0, param1, opts) => {
    opts = opts || {};
    /* ... */
};
Scott Sauyet
@CrossEye
May 31 2016 17:20
Yes. Or const opts = arguments[2] || {}.
I would love to hear of a currying solution that could handle these sorts of variadic functions, but I'm doubtful.
LeonineKing1199
@LeonineKing1199
May 31 2016 17:26
I don't even think currying should solve that problem. Currying is all about managing and applying the right arguments in the right places. That burden might fall on the implementor of the function and not the implementation of the currying function itself.
But it might be possible to implement something in the same vein as the placeholder, using a new optional type, maybe. You could create some logic based around whether or not an argument passed into the curry function isOptional or not.
Scott Sauyet
@CrossEye
May 31 2016 17:29
Our take has always been that there is simply no clean way to curry a function like that. Our curry simply uses the arity your function reports. I just didn't know if you had some insight that might let us move beyond that.
LeonineKing1199
@LeonineKing1199
May 31 2016 17:30
Honestly, I don't think currying can solve that problem, nor should it.
Currying shouldn't care about what's in the function.
Still, I'm happy I went home and spent some time this weekend implementing my own function. I feel good about that.
If people want to implement some weird function, they can. It's outside the scope of the function's responsibilities to care about what instructions are encapsulated by the function that's passed in.
Scott Sauyet
@CrossEye
May 31 2016 17:39
Perhaps, but such functions are very much a part of the JS universe. It would be great if there was some reasonable way to curry them. That's why I didn't discourage you. I'm glad you built your own too.
LeonineKing1199
@LeonineKing1199
May 31 2016 17:43
Out of curiosity, does Ramda's normal curry not already solve this issue? Because in the example I posted, the fixed arity of (param0, param1, opts), you should be able to curry that up to opts and have it behave as expected. Unless I'm missing something there...
Scott Sauyet
@CrossEye
May 31 2016 17:46
Sure, but then fn(a, b) doesn't fire the original function, only returning a new function waiting for the third (supposed-to-be-optional) parameter.
And if you do it the other way, using two named parameters and arguments[2], then you can't find a way to call it with the first two parameters but not have it due right away, when you want a new function that awaits only that last parameter.
Brad Compton (he/him)
@Bradcomp
May 31 2016 17:56
In the specific cases where I've wanted a curried function with optional parameters, I've used curryN. It runs into the second issue you mention @CrossEye , wherein you can't curry it up to the optional parameters. This is typically fine though, it just means having to spend some time up front considering the most reasonable argument ordering.
Scott Sauyet
@CrossEye
May 31 2016 17:58
Yes, that is one of the motivations for curryN. This just seems to be one of those you-can't-have-everything moments.
Man, I still hate this interface on mobile!
LeonineKing1199
@LeonineKing1199
May 31 2016 18:14
So, out of curiosity, could you define the interface a little bit better for me? Like, what's your input and expected output?
Scott Sauyet
@CrossEye
May 31 2016 18:19
No. That's part of the problem. It's hard to figure out even what_ it should do, never mind _how to make it work. We mostly just throw our hands up and say that currying and variadic functions don't play well togther.
suggestions are welcome.
LeonineKing1199
@LeonineKing1199
May 31 2016 18:20
Well, we can't solve a problem that we can't define.
Scott Sauyet
@CrossEye
May 31 2016 18:24
You're looking too far along. Try to define the API first, then think about the implementation. The trouble we've had is that no one has had good API suggestions.
LeonineKing1199
@LeonineKing1199
May 31 2016 22:01
That's fair. So... Can you at least help me answer this, what do we have and what do we want?