DEV Community

Getting started with fp-ts: Reader

Giulio Canti on December 18, 2019

The purpose of the Reader monad is to avoid threading arguments through multiple functions in order to only get them where they are needed. One of...
Read full post
Collapse
 
macsikora profile image
Pragmatic Maciej • • Edited

Very nice functional concept. But I have small concern if the whole typing of that has/or not a big sense. I mean we really use here a HOF and the whole composition h . g . f result is a function with deps argument

const f = (b: boolean) => (deps: Dependencies) => (b ? deps.i18n.true : deps.i18n.false)
const g = (n: number) => f(n > 2)
const h = (s: string) => g(s.length + 1)
Enter fullscreen mode Exit fullscreen mode

For the second, I see some benefit, but not see doing it like below as a bad thing (yes deps are passed explicitly, but is it any issue?)

const f = (b: boolean) => (deps: Dependencies) => (b ? deps.i18n.true : deps.i18n.false)
const g = (n: number) => (deps: Dependencies) => f(n > deps.lowerBound)(deps) 
// above explicit deps which we can use
const h = (s: string) => g(s.length + 1)
Enter fullscreen mode Exit fullscreen mode

Not get me wrong, just thinking if the whole additional piping and typing is beneficial here.

Collapse
 
gcanti profile image
Giulio Canti •

I have small concern if the whole typing of that has/or not a big sense

Well, you are just writing a bunch of functions returning Reader, whether or not you add an explicit type. The point is making the dependencies as implicit as possibile, the key is to put them as a last argument. Note that often people put the dependencies as a first argument

const f = (deps: Dependencies) => (b: boolean) => (b ? deps.i18n.true : deps.i18n.false)
Enter fullscreen mode Exit fullscreen mode

making composition more difficult.

For the second...

all the following gs are equivalent (so feel free to choose the style you prefer)

const g = (n: number) => (deps: Dependencies) => pipe(deps, f(n > deps.lowerBound))

const g = (n: number): Reader<Dependencies, string> => deps => pipe(deps, f(n > deps.lowerBound))

const g = (n: number): Reader<Dependencies, string> => deps => f(n > deps.lowerBound)(deps)

const g = (n: number): Reader<Dependencies, string> =>
  pipe(
    ask<Dependencies>(),
    chain(deps => f(n > deps.lowerBound))
  )
Enter fullscreen mode Exit fullscreen mode
Collapse
 
gunzip profile image
Danilo Spinelli •

I'm used to put deps as the first argument since this lets you partially apply f:

const f = (deps: Dependencies) => (b: boolean): string => (...)

Collapse
 
macsikora profile image
Pragmatic Maciej •

Yes the whole idea has a lot of sense, and I mean adding argument after not before. Thanks for clarifying!

Collapse
 
vicrac profile image
Michał Kaczanowicz •

I'd say there'e no magic in here - in FP all functions have to be referentially transparent at the end of the day i.e. all arguments have to be passed directly! What I think is crucial in here is the conceptual "turning inside-out" (or rather "bottom-up", should I say) - instead of passing props/arguments down multiple levels, we pass a function consuming these props (Reader) multiple levels up, in an almost implicit way. When the Reader reaches "the surface", we can pass its dependencies directly.

Collapse
 
macsikora profile image
Pragmatic Maciej •

Yes I see this in that way also. The whole idea here is in dependency argument in the end and not in the beginning.

In my comment I was more addressing the whole additional idealogy over that, like special typings and using some pipe, ask, chain. I see these as only a fog and complexity over really simple but powerful concept.

Collapse
 
massimilianorango profile image
massimilianorango •

Wow, this looks great! 😍
I'm having trouble understanding how the Reader monad can help in more complex examples though.
Take a look at this for instance: (functions with the "2" suffix are the ones that I would write having dependencies as the first parameter)

export interface Dependencies {
  readonly i18n: {
    readonly true: string
    readonly false: string
  }
  readonly lowerBound: number
}

export interface OtherDependencies {
  readonly semicolon: boolean
}

// Transform:
const transform = (a: string) => (deps: OtherDependencies) =>
  `myString${deps.semicolon ? ':' : ''} ${a}`

const transform2 = (deps: OtherDependencies) => (a: string) =>
  `myString${deps.semicolon ? ':' : ''} ${a}`

// AnotherTransform:
const anotherTransform = (a: string) => (deps: OtherDependencies) =>
  `${a}${deps.semicolon ? ':' : ''} myString`

const anotherTransform2 = (deps: OtherDependencies) => (a: string) =>
  `${a}${deps.semicolon ? ':' : ''} myString`

// F:
const f = (b: boolean) => (deps: Dependencies) =>
  pipe(
    b,
    ifElse(equals(true), always(deps.i18n.true), always(deps.i18n.false))
  )

const f2 = (deps: Dependencies) =>
  ifElse(equals(true), always(deps.i18n.true), always(deps.i18n.false))

// G:
const g = (n: number) => (deps: Dependencies & OtherDependencies) =>
  pipe(
    n > 2,
    f,
    ff => ff(deps),
    s => transform(s)(deps),
    s => anotherTransform(s)(deps)
  )

const g2 = (deps: Dependencies & OtherDependencies) =>
  flow(
    (n: number) => n > 2,
    f2(deps),
    transform2(deps),
    anotherTransform2(deps)
  )
Enter fullscreen mode Exit fullscreen mode

In particular, notice how:

  1. f needs to make b explicit even if could be implicit (like it is in f2)
  2. all the functions in the g pipe need to take the result from the previous computation and pass it as the first parameter to the transform functions, while this is implicit in g2. This leads to less readable code and harder composition. Is there something I'm missing?
  3. Is it generally right to merge all the dependencies of the functions used by g like I did with Dependencies & OtherDependencies?
Collapse
 
gcanti profile image
Giulio Canti • 
import { pipe } from 'fp-ts/lib/pipeable' // v2.6
import { chainW, Reader } from 'fp-ts/lib/Reader'

export interface Dependencies {
  readonly i18n: {
    readonly true: string
    readonly false: string
  }
  readonly lowerBound: number
}

export interface OtherDependencies {
  readonly semicolon: boolean
}

declare function transform(a: string): Reader<OtherDependencies, string>
declare function anotherTransform(a: string): Reader<OtherDependencies, string>
declare function f(b: boolean): Reader<Dependencies, string>

const g = (n: number) => pipe(f(n > 2), chainW(transform), chainW(anotherTransform))
Collapse
 
massimilianorango profile image
massimilianorango •

That's exactly what I needed. I saw you just released chainW in 2.6.0. Great job thanks! :)

Collapse
 
cyberixae profile image
Toni Ruottu •

Do we have a standard name for (r: Reader<R,A>) => A?

import { Reader } from 'fp-ts/lib/Reader';

type Provider<R> = <A>(r: Reader<R,A>) => A

type Name = string
type Age = number

type Customer = {
  name: Name,
  age: Age,
}

const john: Provider<Customer> = (r) => r({
  name: 'John Doe',
  age: 42,
})

const getAge: Reader<Customer, Age> = ({age}) => age

const ageJohn: Age = john(getAge);
Enter fullscreen mode Exit fullscreen mode
Collapse
 
gcanti profile image
Giulio Canti •

Yoneda? Provider<R> is isomorphic to R

Collapse
 
fp_apprentice profile image
λ fp-apprentice •

Whoops, my brain is starting to melt, but I like all of this. :)

Collapse
 
fp_apprentice profile image
λ fp-apprentice •

Wait, wait, I get it now

Collapse
 
ehaynes99 profile image
Eric Haynes •

I know this is an older post, I'm having trouble understanding how this fixes the original issue.

As you can see, h and g must have knowledge about f dependencies despite not using them.

That's true after the refactor as well. Dependencies of f are part of g and h signatures. The way the example is written, the problem is compounded when g has a dependency, because now f depends on parameters of g as well. They could be distinct types, but dependencies of g must be a superset of dependencies of f, e.g.

type FDependencies = { /* ... */ }
type GDependencies = { lowerBound: number } & FDependencies
Enter fullscreen mode Exit fullscreen mode

I understand the desire to curry them so that we can pipe things together, but we haven't lessened the pain of refactoring here at all.

Even if g did not directly call f but was instead piped to it, would it not be better suited to have a flavor of flow or pipe that would automatically coalesce the dependencies?

Collapse
 
aabccd021 profile image
aabccd021 •

Great article!
I'd love to see another article about Writer using fp-ts.