question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Applicative interface is wrong

See original GitHub issue

Hello, why your interface differ of Folktale maybe in applicative. https://github.com/folktale/data.maybe/blob/master/lib/maybe.js#L206

Your suggestion:

const state: any = {
  b: {}
}
const a = Maybe.of(state).get('b').map(() => (num: number) => num * num)
const b = Maybe.of(234)
console.log(a.ap(b))

But I can’t use that as chain. I could do such:

const indentity = <T>(a: T): T => a
const state: any = {
  b: {}
}
const a = Maybe.of(state).get('b').map(() => (num: number) => num * num).unwrapOr(indentity)
const b = Maybe.of(234)
console.log(b.map(a))

But it’s a crutch. How it must be actually:

const state: any = {
  b: {}
}
const a = Maybe.of(state).get('b').map(() => (num: number) => num * num)
const c = Maybe.of(state).get('b').get('c').map(() => (num: number) => num * num)
const b = Maybe.of(234)
console.log(b.ap(a).ap(c))

Issue Analytics

  • State:closed
  • Created 4 years ago
  • Comments:6

github_iconTop GitHub Comments

2reactions
chriskrychocommented, May 9, 2019

You’re welcome!

2reactions
chriskrychocommented, May 9, 2019

You’re just not lining up your types correctly. 😄 The interface works just the way it should; please dig in further with the types and docs! What you’re wanting to do you can do if you pull in a library like Ramda or lodash and use their compose functions, but you cannot call .ap on a type which not a Maybe<Function>—that doesn’t actually make sense, type-wise!

Here’s how your example looks using the types correctly:

function f(data: Data, state: number): number {
  const multC = Maybe.of(data).get('b').get('c').map((c) => (n: number) => n * c);
  const addD = Maybe.of(data).get('d').map((d) => (n: number) => n + d);
  const result = Maybe.of(state);

  let multipliedC = multC.ap(result);
  let addedD = addD.ap(multipliedC);

  return addedD.or(multipliedC).or(addD.ap(result)).unwrapOr(0);
}

Notice that the fact that this is not “chain-able” is not a bug: it’s what the types require! And the functions won’t be applied when the underlying value isn’t present, exactly as you like.

What you’re actually looking for here is a compose function. True Myth doesn’t supply this because it’s not trying to be a library for all functional programming—especially because other libraries already do this well and work perfectly nicely with True Myth. For example, if you were using Ramda’s pipe function (left composition rather than the usual right composition), you could write this:

function f(data: Data, state: number) {
  const multC = Maybe.of(data).get('b').get('c').map(c => (n: number) => n * c);
  const addD = Maybe.of(data).get('d').map(d => (n: number) => n + d);
  const result = Maybe.of(state);
  
  const bothOrEitherOr0 = pipe(
    Maybe.ap(multC),
    Maybe.ap(addD),
    Maybe.or(multC.ap(result)),
    Maybe.or(addD.ap(result)),
    Maybe.unwrapOr(0),
  );
  
  return bothOrEitherOr0(result);
}

This gives you exactly the results you’re looking for, including lazy evaluation of the functions.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Beyond Monad: The Applicative Interface | by Ross | The Startup
The Applicative Interface is very simple, even simpler than the Monad Interface, but I think it's even more powerful because it's actually ...
Read more >
How to handle side effect with Applicative? - Stack Overflow
Which is cool but I can't see how that links to side effects. My understanding is that Applicative is a weak monad and...
Read more >
10 Examples Of Bad UI Design And How To Fix Them
1. Pointless inconsistency in your UI elements · Consistent use of color palette for elements like buttons, text, links, header, footer, hover ...
Read more >
Why Changing an Interface Too Often Is Bad for Users
Despite what a lot of application developers think, changing a user interface too often is bad for users. It confuses users and generally ......
Read more >
Top 10 Application-Design Mistakes - Nielsen Norman Group
1. Poor Feedback. One of the most basic guidelines for improving an application's usability is to provide clear feedback: · 2. Inconsistency ·...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found