Discussion on: Getting started with fp-ts: Reader

[Pragmatic Maciej]

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)

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)

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

[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)

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))
  )

[Pragmatic Maciej]

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

[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 => (...)

[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.

[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.

[Giulio Canti]

There's a benefit in using the monadic interface though: software is written in a uniform style, regardless of the effect.

You can think of Reader as an effect, muck like Either or Task.

Let's say you have the following snippet

import * as E from 'fp-ts/lib/Either'
import { pipe } from 'fp-ts/lib/pipeable'

declare function f(s: string): E.Either<Error, number>
declare function g(n: number): boolean
declare function h(b: boolean): E.Either<Error, Date>

// composing `f`, `g`, and `h` -------------v---------v-----------v
const result = pipe(E.right('foo'), E.chain(f), E.map(g), E.chain(h))

const pointFreeVersion = flow(f, E.map(g), E.chain(h))

and at some point you must refactor f to

import * as RE from 'fp-ts/lib/ReaderEither'

interface Dependencies {
  foo: string
}

declare function f(s: string): RE.ReaderEither<Dependencies, Error, number>

result and pointFreeVersion must be refactored as well, fortunately you can use ReaderEither's monadic interface

// before 
const result = pipe(E.right('foo'), E.chain(f), E.map(g), E.chain(h))

const pointFreeVersion = flow(f, E.map(g), E.chain(h))

// after
const result = pipe(
  RE.right('foo'),
  RE.chain(f),
  RE.map(g),
  RE.chain(b => RE.fromEither(h(b)))
)

const pointFreeVersion = flow(
  f,
  RE.map(g),
  RE.chain(b => RE.fromEither(h(b)))
)

[Michał Kaczanowicz]

There's a benefit in using the monadic interface though: software is written in a uniform style, regardless of the effect.

I was just about to say it: I think main benefit is (ironically) readability - by saying explicitly Reader<Dependencies, string> you clearly communicate your intent (assuming others know the concept as well, of course 😄).

[Giulio Canti]

That's right, you write programs by composing kleisli arrows A -> M<B>, for some effect M.

So Reader (or ReaderEither, ReaderTaskEither, Option, Either, etc...) is just one of the possible effects