These are chat archives for ramda/ramda

17th
May 2017
Rob Hilgefort
@rjhilgefort
May 17 2017 00:19
Is ther a way to use a value you just set on an object inside a pipeline?
something like…
pipe(
  always({ foo: ‘foo’, bar: ‘bar’ }),
  // access `foo` and `bar` to set a new property `baz`?
)
Bijoy Thomas
@bijoythomas
May 17 2017 00:27
Might be an overkill but ..
pipe(
  always({ foo: 'foo', bar: 'bar' }),
  lift((fooVal, barVal, obj) => assoc('new', fooVal + barVal, obj))(prop('foo'))(prop('bar'))(identity)
)()
Rob Hilgefort
@rjhilgefort
May 17 2017 00:28
does seem like a mouthfull
what would you recommend instead?
jump out of the pipe? trying keep it point-free
might be going overboard with that aim though
Bijoy Thomas
@bijoythomas
May 17 2017 00:31
if you have the values, can you do it in one shot with merge?
merge({}, {foo: 'foo', bar: 'bar', newKey: 'foo' + 'bar'})
Zephilim
@Zephilim
May 17 2017 13:12

I have an array of object items where each item has a property called "long" and a property called "short". This collection is being used as a look to enable looking up the long name of an object given its short name.

So if I had a target object: target = { name: "p" } and a lookup sequence:

[ { long: "pinky", short: "p" }, { long: "turky", short: "t" } ]

I would like to change the target's object name to be "pinky".

Further more, I would like to perform this transformation on an array of target objects, so an R.map() of some description would be in order, with a condition, because the target objects may already have the long name so should remain unchanged, but those targets with a short name would have their name mutated to the long name.

I have started off with the following test suite, but I am coming a cropper at an early stage:

  describe.only("Map short arg name to long option name", () => {

    let getLongNameFn = R.prop("long");
    let ifShortNameIs_p_Fn = R.propEq("short", "p");
    let ifShortNameIsFn = R.propEq("short");
    let option = { long: "pinky", short: "p" };

    it("get long name", () => { // THIS TEST PASSES
      expect(getLongNameFn(option)).to.be.equal("pinky");
    });

    it("if short name eq to p", () => { // THIS TEST PASSES
      expect(ifShortNameIs_p_Fn(option)).to.be.true;
    });

    it("if short name eq to <something>", () => { // THIS TEST FAILS

      let ifShortOptionNameEqual = ifShortNameIsFn(option);

      expect(ifShortOptionNameEqual("p")).to.be.true;
    });
  });

The last test: "if short name eq to <something>", is failing, I'm expecting the "short" property name of the target
object: "option" to be "p", but the expectation is returning false.

Confused! Can you help, thanks.

Bijoy Thomas
@bijoythomas
May 17 2017 13:42
You are passing arguments to ifShortNameIsFn in the wrong order. Your partially applied function should look like
let ifShortOptionNameEqualP = ifShortNameIsFn('p) and then
expect(ifShortOptionNameEqualP(option)).to.be.true
Zephilim
@Zephilim
May 17 2017 14:21
Bijoy, thanks for that
Bijoy Thomas
@bijoythomas
May 17 2017 14:24
you're welcome
Zephilim
@Zephilim
May 17 2017 14:25
Problem with functional programming is that its easy to write code that looks simple and looks to makes sense, but is flat out wrong :(
Michael Rosata
@mrosata
May 17 2017 14:26
@Zephilim and it's easy to write code that looks complex and appears to make no sense, but is also flat out wrong :smile:
Zephilim
@Zephilim
May 17 2017 14:26
Yup!
Shawn Talbert
@ShawnTalbert
May 17 2017 14:26
agreed on both counts!
Bijoy Thomas
@bijoythomas
May 17 2017 14:27
@Zephilim maybe you are already doing this, but if not, the online Ramda REPL is a great place to try out Ramda functions
Zephilim
@Zephilim
May 17 2017 14:28
Yeah, I'm doing a bit of that mixed with writing test cases
Funny thing is, I used to do a lot of functional programming (without realising it) in C++ with the boost library but I don't remember feeling as flumuxed as I do with Ramda/JS
Gabe Johnson
@gabejohnson
May 17 2017 17:56
I'd like to get some feedback from people in this channel regarding #2177
Michael Rosata
@mrosata
May 17 2017 17:56
@gabejohnson I started some feedback a few hours ago and then had a meeting
Brad Compton (he/him)
@Bradcomp
May 17 2017 17:56
Like, here or in the comments there?
Robert Mennell
@skatcat31
May 17 2017 17:57
hahaha I did a gist on github awhile ago about infix operations XD
Gabe Johnson
@gabejohnson
May 17 2017 17:57
@Bradcomp either one. If you want to discuss it here that'd be great though
@mrosata great! I look fwd to seeing it
@mrosata I just added another alternative
Brad Compton (he/him)
@Bradcomp
May 17 2017 17:59
I know that some people want to get rid of the placeholder (__), but I think it solves the same issue that the sections are supposed to solve.
Gabe Johnson
@gabejohnson
May 17 2017 18:01
I think the issue w/ __ is that it complicates the implementation of some internal functions like curryN
I just added a suggestion to repurpose the placeholder
Brad Compton (he/him)
@Bradcomp
May 17 2017 18:01

I like the infix function, even though it seems unnecessary.

const on = (f, g) => useWith(f, [g, g]);

ifx(lt, on, prop('date'));

Reads quite nicely

I just saw your new proposal. I can see how the placeholder complicates things significantly. From an ergonomics standpoint it's really nice though
Gabe Johnson
@gabejohnson
May 17 2017 18:02
how about
const on = (f, g) => useWith(f, [g, g]);

__(lt, on, prop('date'));
__(__, on, prop('date'))(lt);
__(lt, on, __)(prop('date'));
Michael Rosata
@mrosata
May 17 2017 18:03
I do like the notation _f and f_ over _r and _l. In either case it did take me a few minutes to wrapping my brain around correct usage. I think no matter what there will be a small mental leap. It will never be as simple as (+3) or (+3) unfortunately. I do really like it though. I'll have to go look at the update
Denis Stoyanov
@xgrommx
May 17 2017 18:03
i don't like it
if u want infix -> use livescript
Gabe Johnson
@gabejohnson
May 17 2017 18:04
@xgrommx the purpose is to resolve a long standing issue w/ non-commutative, associative binary operators
#1497
Brad Compton (he/him)
@Bradcomp
May 17 2017 18:09
Repurposing the placeholder doesn't look bad, but it seems like it would complicate internals further. Also, it really isn't obvious up front what it is doing.
Gabe Johnson
@gabejohnson
May 17 2017 18:10
I think it would simplify internals if it were only usable as an argument to itself
Brad Compton (he/him)
@Bradcomp
May 17 2017 18:13
So then __ becomes the infix function, and sections are really just infix functions with the placeholder.
I don't mind that... it's growing on me
Would __ be curried, or would you always need to provide all three values? (I would probably vote for the latter)
Gabe Johnson
@gabejohnson
May 17 2017 18:15
@Bradcomp I don't know how you avoid the latter. How do you identify which is the operator otherwise?
I'm thinking about FL dispatching
Brad Compton (he/him)
@Bradcomp
May 17 2017 18:19
Well __(lt, on, __) and __(lt, on) would be equivalent, but I don't really like that other than that it would make the function behave the same as all other Ramda functions
Gabe Johnson
@gabejohnson
May 17 2017 18:20
I see this as being more akin to a function masquerading as a syntactic extension
Brad Compton (he/him)
@Bradcomp
May 17 2017 18:21
haha, yeah.
Gabe Johnson
@gabejohnson
May 17 2017 18:22
Something like
function __(a, f, b) {
  if (a === __) return function(a) { return f(a, b); }
  if (b === __) return function(b) { return f(a, b); }
  return f(a, b);
}
Michael Rosata
@mrosata
May 17 2017 18:22
yea, that's not such a bad idea
Brad Compton (he/him)
@Bradcomp
May 17 2017 18:23
I like the idea of one function handling all three cases
And that is a fairly straightforward function for sure
Gabe Johnson
@gabejohnson
May 17 2017 18:24
I'm pasting it into my personal utilities file right now :smile:
Brad Compton (he/him)
@Bradcomp
May 17 2017 18:24
haha
Gabe Johnson
@gabejohnson
May 17 2017 18:25
You could even still use this as the current placeholder and then deprecate that usage in the near future
I think R.__ is just identified internally in case analysis
So really this would be an extension of R.__ and subsequent deprecation of the current usage
Brad Compton (he/him)
@Bradcomp
May 17 2017 18:29
Personally, I still like the placeholder :stuck_out_tongue: . I may be in the minority with that opinion though
Michael Rosata
@mrosata
May 17 2017 18:30
no I agree with you @Bradcomp
Robert Mennell
@skatcat31
May 17 2017 18:30
Sometimes I feel like the placeholder is helpful, and other times a logical crutch
Michael Rosata
@mrosata
May 17 2017 18:34
I don't use the placeholder much, even in situations where I should be using it (the ones that the infix operator would solve) I usually use some confusing combination of Cor flip, but I've used it to explain partial application a few times and I think someone who came to Ramda that was just learning FP would get a lot out of the __ placeholder because it works well with functions not designed to be of the functional variety. (if that makes sense)
Brad Compton (he/him)
@Bradcomp
May 17 2017 18:36
I tend to prefer it over flip for readability in many cases. contains(__, potentialValues) in a composition being a common case.
Michael Rosata
@mrosata
May 17 2017 18:37
yea, it's much preferable over flip. My brain just fails me every-time the situation arises
Brad Compton (he/him)
@Bradcomp
May 17 2017 18:37
haha, I feel ya
Brad Compton (he/him)
@Bradcomp
May 17 2017 18:39
__(listOfValues, flip(contains), __) :expressionless:
function __(a, f, b) {
  if (a === __) return function(a) { return f(a, b); }
  if (b === __) return function(b) { return f(a, b); }
  return f(a, b);
}
__['@@functional/placeholder'] = true;
And there you go :stuck_out_tongue:
Michael Rosata
@mrosata
May 17 2017 18:40
so you could do
module.exports = function _isPlaceholder(a) {
  return /* a != null && */
         typeof a === 'function' &&
         a['@@functional/placeholder'] === true;
};
Denis Stoyanov
@xgrommx
May 17 2017 18:41
bullshit
Gabe Johnson
@gabejohnson
May 17 2017 18:41
no
@Bradcomp yes
@mrosata sorry. yes
you could get rid of a != null though
@xgrommx can you elaborate?
Brad Compton (he/him)
@Bradcomp
May 17 2017 18:43
return a['@@functional/placeholder'] === true; :question:
I guess that would throw, nvm
Michael Rosata
@mrosata
May 17 2017 18:48
Well, I'll thumbs up it if you propose it. Until then folks, I'm outta here :hatching_chick:
Bijoy Thomas
@bijoythomas
May 17 2017 20:04
@gabejohnson how would this work with compose? Can compose be used an as infix operator with your change?
Gabe Johnson
@gabejohnson
May 17 2017 20:32
@bijoythomas yes