Start working on v2

[gcanti]

@sledorze @raveclassic @grossbart

I was waiting for microsoft/TypeScript#26349 in order to start working on fp-ts@2.x but alas looks like it will be delayed for an indefinite period.

The current codebase has accumulated some cruft during the last few months, which is a good thing because fp-ts is now way better than say a year ago, but is also much confusing for new comers.

I think it's time to clean up the codebase and release a polished fp-ts@2.x version:

• remove all the deprecated APIs / modules
• remove all phantom fields
• other changes? (please help me with this)

What do you think?

[sledorze]

@gcanti
We may also reconsider/refresh/restate on that one:
#543

[raveclassic]

@gcanti Awesome!

Sidenote - should we wait for microsoft/TypeScript#30790 and try to implement generator-based do-notation once again and add it to the core if succeeded?

[sledorze]

@raveclassic is that performant? (sorry not checked by thinking that is not the case)

[sledorze]

Some pain points I've seen so far around the HKT encoding (without any proposition):

• People have a hard time when somewhere they broke a module augmentation and don't have a clue as where the breaking comes from.
• People don't know where to put their instances; Haskell/Purescript drives you on that matter.

Maybe we can find some solutions to those, if the solutions result in a breaking change that may be the right time to discuss it

[raveclassic]

@sledorze I haven't checked performance. Still I think ability to write do-notation-like code is a greater benefit anyway. However current implementation is stack-unsafe.

[grossbart]

I like what was listed already 👍 Here's some more (completely random) ideas:

• My team was very confused with the 2v modules (“what is this and why is it there?”), so if these will replace the deprecated modules that is a good thing for version 2, I think. (I personally do like this approach to prevent breaking existing code, but I understand the confusion, too.)
• Maybe we could also rethink some harder to use APIs. An example I have here is liftA<n> where the applied function is curried and has to be manually typed; the way I understand this a simplification along the lines of liftA2(option)((a, b) => {}, optA, optB) could make type inference for the arguments a and b work. (I could be mistaken and it might be that I just couldn't figure out how to make type inference work 😄.)
• Functions like groupBy could return a Map (see also this issue: Record keys should be string | number | symbol instead of only string #730, for example).
• Figure out how to best work with ReadonlyArrays Array.last: add support for ReadonlyArray #544, after all FP is all about not mutating things.
• Maybe a similar issue arises for tuples, now that they can be made readonly in TS3.4?
• This would be a good time to replace the deprecated inspect functions for Node with the new way to do it Node 10 DeprecationWarning #408

[gcanti]

@grossbart RE: liftA<n>. Now that we have sequenceT / sequenceS I think we can deprecate the liftA<n> functions.

Moreover they don't play well with polymorphic functions

import { liftA2 } from 'fp-ts/lib/Apply'
import { option } from 'fp-ts/lib/Option'

const toObj = <A>(a: A) => <B>(b: B): { a: A; b: B } => ({ a, b })

const toObjLifted = liftA2(option)(toObj)
/*
Note the inferred `{}`

const toObjLifted: <A>(a: Option<A>) => (b: Option<{}>) => Option<{
    a: A;
    b: {};
}>
*/

I'll send a PR (for v1.17)

liftA2(option)((a, b) => {}, optA, optB) usually is named map2, see #322

[sledorze]

Another thing I've seen is unlawful implementation of instances.
It may be useful to find a way to enforce lawfulness (or at least ease it / make it the default).

[gcanti]

RE: inspect / toString. I propose to skip over the issue by introducing the Show type class (I'll send a PR)

[grossbart]

Thanks for the liftA<n> explanation: makes a lot of sense! I will try to think of a way to make this findable in the docs – for example, some on our team have struggled with finding Maybe, not knowing that some languages use Option for this concept, and this is a similar kind of problem: people will try to find what they know 😄 I didn't know about map<n>, either.

And I'm completely on board with the Show typeclass 👍

[gcanti]

Do we also want to switch to "naked" data types?

A glaring example: Writer.

There's no much of a benefit of using a class (only map as a method)

export class Writer<W, A> {
  constructor(readonly run: () => [A, W]) {}
  map<B>(f: (a: A) => B): Writer<W, B> {
    return new Writer(() => {
      const [a, w] = this.run()
      return [f(a), w]
    })
  }
}

We could switch to a unwrapped representation

export interface Writer<W, A> {
  (): [A, W]
}

We could also declassify

• Identity
• Pair
• Tuple

and maybe also

• State
• Reader
• ReaderTaskEither

[sledorze]

Note: One of the reasons for preferring instantiating a class over a POJO ( :) ), is the cost of construction (depending on the number of methods/functions).

[gcanti]

@sledorze I mean just the function (no POJO)

Here's the Writer module as an example

import { phantom } from './function'
import { Functor2 } from './Functor'
import { Monad2C } from './Monad'
import { Monoid } from './Monoid'

declare module './HKT' {
  interface URI2HKT2<L, A> {
    Writer: Writer<L, A>
  }
}

export const URI = 'Writer'

export type URI = typeof URI

/**
 * @since 1.0.0
 */
export interface Writer<W, A> {
  (): [A, W]
}

export const evalWriter = <W, A>(fa: Writer<W, A>): A => {
  return fa()[0]
}

export const execWriter = <W, A>(fa: Writer<W, A>): W => {
  return fa()[1]
}

const map = <W, A, B>(fa: Writer<W, A>, f: (a: A) => B): Writer<W, B> => {
  return () => {
    const [a, w] = fa()
    return [f(a), w]
  }
}

/**
 * Appends a value to the accumulator
 *
 * @since 1.0.0
 */
export const tell = <W>(w: W): Writer<W, void> => {
  return () => [undefined, w]
}

/**
 * Modifies the result to include the changes to the accumulator
 *
 * @since 1.3.0
 */
export const listen = <W, A>(fa: Writer<W, A>): Writer<W, [A, W]> => {
  return () => {
    const [a, w] = fa()
    return [[a, w], w]
  }
}

/**
 * Applies the returned function to the accumulator
 *
 * @since 1.3.0
 */
export const pass = <W, A>(fa: Writer<W, [A, (w: W) => W]>): Writer<W, A> => {
  return () => {
    const [[a, f], w] = fa()
    return [a, f(w)]
  }
}

/**
 * Projects a value from modifications made to the accumulator during an action
 *
 * @since 1.3.0
 */
export const listens = <W, A, B>(fa: Writer<W, A>, f: (w: W) => B): Writer<W, [A, B]> => {
  return () => {
    const [a, w] = fa()
    return [[a, f(w)], w]
  }
}

/**
 * Modify the final accumulator value by applying a function
 *
 * @since 1.3.0
 */
export const censor = <W, A>(fa: Writer<W, A>, f: (w: W) => W): Writer<W, A> => {
  return () => {
    const [a, w] = fa()
    return [a, f(w)]
  }
}

/**
 *
 * @since 1.0.0
 */
export const getMonad = <W>(M: Monoid<W>): Monad2C<URI, W> => {
  const of = <A>(a: A): Writer<W, A> => {
    return () => [a, M.empty]
  }

  const ap = <A, B>(fab: Writer<W, (a: A) => B>, fa: Writer<W, A>): Writer<W, B> => {
    return () => {
      const [f, w1] = fab()
      const [a, w2] = fa()
      return [f(a), M.concat(w1, w2)]
    }
  }

  const chain = <A, B>(fa: Writer<W, A>, f: (a: A) => Writer<W, B>): Writer<W, B> => {
    return () => {
      const [a, w1] = fa()
      const [b, w2] = f(a)()
      return [b, M.concat(w1, w2)]
    }
  }

  return {
    URI,
    _L: phantom,
    map,
    of,
    ap,
    chain
  }
}

/**
 * @since 1.0.0
 */
export const writer: Functor2<URI> = {
  URI,
  map
}