These are chat archives for ramda/ramda

28th
May 2017
Jason Shin
@JasonShin
May 28 2017 01:07 UTC
which style would you prefer?
async function doSomething(param) {
  const result1 = await test1(param)
  const result2 = await test2(result1.thingy)
  if (!result2.status) {
    throw new Exception()
  }
  return result2
}
const doSomething = R.compose(
  ifElse(x => x.status ? x : new Exception())
  test2,
  test1
)
doSomthing(param)
both style contains side effects
but you cannot avoid them TBH
Michael Zinn
@RedNifre
May 28 2017 01:51 UTC
Ravr (Ramda.js for Java) now has a big table in the Readme that shows which functions are already ported: https://github.com/RedNifre/ravr Java Devs, which functions do you need the most?
Tom Harding
@i-am-tom
May 28 2017 07:21 UTC
@JasonShin The first one is so much more readable to me. You can definitely drop the side-effects, though, if you define your test functions as Task or Future elements:
//+ doSomething :: Task String Result
const doSomething = param =>
  test1(param)
  .chain(({ thingy, status }) =>
    test2(thingy)
    .chain(result => new Task((rej, res) =>
      status ? rej(‘BAD STATUS’)
             : res(result))))
Denis Stoyanov
@xgrommx
May 28 2017 07:45 UTC
@buzzdecafe I forgot about it :smile:
Jason Shin
@JasonShin
May 28 2017 09:04 UTC
@i-am-tom hmm right.. I honestly still don't understand how Future or Task is any different than await test1 await test2, which are promise based. When test1 or test2 fails, they will return bad status. I think I'm confused about "side effect" in general. In above code which is about making HTTP request to a server, I thought side effects mean errors from the server (50x). So what the hell is side effects?
Tom Harding
@i-am-tom
May 28 2017 09:06 UTC

ah, no - side effect is something actually happening (e.g. your request). In purely-functional programming, you don’t do the thing, you describe how you want to do it. It just so happens that functions are a really neat way to describe something you want to do. When you want to do the thing, your code becomes impure, due to side-effects.

console.log(‘hi’)

^ That is impure. It has the side-effect of updating the terminal.

(() => console.log(‘hi’))

^ That isn’t. It’s a description of a program that updates the terminal. When we run it, however, we’ll execute the impure action (the side effects)

Jason Shin
@JasonShin
May 28 2017 09:11 UTC
nice
I get it now
Tom Harding
@i-am-tom
May 28 2017 09:12 UTC
The principle is we try to combine all our descriptions into one single description, and the execution of that is the only impurity in our entire app
Jason Shin
@JasonShin
May 28 2017 09:33 UTC
right

hmm, then if I make a separate function of


new Task((rej, res) =>
      status ? rej(‘BAD STATUS’)
             : res(result))

put it in a different file and use it like

//+ doSomething :: Task String Result
const doSomething = param =>
  test1(param)
  .chain(({ thingy, status }) =>
    test2(thingy)
    .chain(theTask)
is that impure?
Jason Shin
@JasonShin
May 28 2017 09:41 UTC
I guess it's not
because we are encapsulating the execution
so it's pure
Tom Harding
@i-am-tom
May 28 2017 10:40 UTC

Yeah. Basically, you can wrap any promise in a Task:

new Task ((rej, res) => myPromiseReturningFun.then(res).catch(rej)

and that won’t do anything until you fork the Task