Fp-ts: Consider dropping support for mutable modules

[gcanti]

Namely:

• Array
• Map
• NonEmptyArray
• Record
• Set
• Tuple

[SRachamim]

As a functional library it's OK to enforce immutability.

I would get rid of all Readonly* modules and make the rest immutable.

[mlegenhausen]

Would love to see that readonly is the default in the whole fp-ts ecosystem but I already had my struggle to switch to the readonly instances with fp-ts@2 because fp-ts-contrib, io-ts-types and monocle-ts has not full readonly support. If we could add the readonly instances e. g. ReadonlyZipper for fp-ts-contrib, readonlyNonEmptyArray for io-ts-types and indexReadonlyNonEmptyArray for monocle-ts I would already give it a try.

[gcanti]

and indexReadonlyNonEmptyArray for monocle-ts

@mlegenhausen https://github.com/gcanti/monocle-ts/pull/124

[gcanti]

I would get rid of all Readonly* modules and make the rest immutable

There are two options I guess:

Option 1

Keep the Readonly* modules and simply remove the mutable counterparts (:+1: if you prefer this option)

Option 2

Remove all the mutable modules and rename Readonly<X> module to <X> (:-1: if you prefer this option)

[gkamperis]

@gcanti based on a similar conversation...

this explains my vote :)

[SRachamim]

We can see this issue in two lights:

1. We're dealing with a strongly-typed pure functional library. We're expecting only readonly data-structures and we're promising to give back only readonly data structures. In this case, the immutability is an axiom, and we don't need to explicitly prefix all our data-structures with a Readonly prefix. We'll have one Array module which is readonly.

...or:

1. We're a _TypeScript_ library, in which the default is mutable structures. There is already a convention of prefixing with Readonly all immutable data-structures. This is aligned with the current situation, in which we have both mutable Array and immutable ReadonlyArray.

I tend to like the first philosophy.