1.0.0

[gcanti]

@raveclassic @sledorze

Changelog: see commits

Try: npm i gcanti/fp-ts#next

[gcanti]

Ok, published on npm

• fp-ts@next (fp-ts@1.0.0-rc)
• io-ts@next (io-ts@0.9.8-rc)
• monocle-ts@next (monocle-ts@0.5.3-rc)
• io-ts-types@next (io-ts-types@0.2.5-rc)
• newtype-ts@next (newtype-ts@0.1.3-rc)

Except fp-ts, the other packages should NOT have API breaking changes

[raveclassic]

Should 1.0-rc briefly describe the breaking changes in readme?

[gcanti]

Those releases are mainly for early feedback, I'm waiting to update the documentation when things settle down and we are satisfied by the result.

Namely

• changelog (will be huge)
• docs/HKT.md

Conversely examples and exercises should be up to date

[sledorze]

@gcanti Here I will consolidate the issues I encounter:

Problem with Either predicates.

Previous version:

        import { either } from 'fp-ts'
...
        arrayOfEithers
        .filter(either.isRight) // predicate
        .map(x => ...) // x is Right<..> :)

New version:

        arrayOfEithers
        .filter(x => x.isRight()) // predicate refines x 
        .map(x => ...) // x is Either<..> :(

We're missing a top level support:

export const isRight = <A, B>(x: either.Either<A, B>): x is either.Right<A, B> =>
  x.isRight()

Note that the same reasoning applies to other Sum types.. (Option, These, ..)

[gcanti]

@sledorze I would argue that using Right as a type is wrong: Right is a constructor not a type (well in TypeScript is also a type because of the implementation and because I'm forced to export Left and Right by TypeScript itself but should be considered as an implementation detail)

In PureScript for example you can't use Right as a type

data Either l r = Left l | Right r

x :: Right String -- doesn't compile
x = Right "foo"

x :: Either Number String -- ok
x = Right "foo"

p.s.

Also in your particular case there's Array.rights

[sledorze]

@gcanti this is not on an array but on (rxjs) observables the use case is not easy without those refinements (sorry for having over simplified the example).
The only solution is to recreate that top level predicate (idiomatic) OR to define another Observable combinator (which a end user would see as the least solution).
Also Right, as implemented, is a type in typescript and its usage is very useful and idiomatic; why restricting it to the possibilities of Purescript.
That's why I think we should (re)add it (based on a real world code base).

[sledorze]

@gcanti
Note on the order of params.
I see that Functor and Chain params are now inverted like so:

chain: <A, B>(fa: HKT<F, A>, f: (a: A) => HKT<F, B>) => HKT<F, B>;
map: <A, B>(fa: HKT<F, A>, f: (a: A) => B) => HKT<F, B>;

But on Apply that's not the case:

ap: <A, B>(fab: HKT<F, (a: A) => B>, fa: HKT<F, A>) => HKT<F, B>;

is it deliberate? (if so, why?)

[gcanti]

why restricting it to the possibilities of Purescript

PureScript is my reference when it comes to establish what's good and what's bad, in particular with respect to functional programming.

However if there is consensus I'm ok to re-add those custom guards because

• clearly you find them useful
• one less breaking change

[sledorze]

Ok anyway i m adding the missing bits into a file so that we can review it later.

[gcanti]

is it deliberate? (if so, why?)

Based on my early experiments there's no gain in terms of type inference / suggestions by swapping the Apply arguments. I'll investgate further though

[sledorze]

@gcanti i was specifically thinking about approachability by homogeneity (if not, wondering what s the default/preferred behavior)

[sledorze]

@gcanti I find we lack meaningful definition for Ordering (I miss LT, EQ, GT) even if they map to -1, 0, 1 in the end.

[sledorze]

@gcanti Ok so I've ported our code base on the new version.

Notable:

• A lot of foldL usage (63).

• new order of args leads to better inference AND looks better also with prettier; often we can see everything in the first line as the biggest param (the function) is the last one.

• Took me a bit of time to understand there was new Monad1, Monad2, etc.. while porting some monadTransformers.

• miss the isRight / isSome a lot in the front-end side (observables) by our frontEnd guy; for that kind of two stage usages: opt$.filter(isSome).map(x => x.value).

• no array.concat; I'm using array.flatten, I don't know if it's better or not performance wise.

• Less type params to write explicitly.

Overall, I would consider this version as ready for usage.

[sledorze]

@gcanti oh I forgot to say that io-ts-types are not referencing the new libs explicitly.
That prevents me to share the new repo internally.

[gcanti]

@sledorze great feedback, thanks

miss the isRight / isSome

ok I'm going to re-add them (*)

no array.concat

you can import concat either from the function module or calling Array.getSemigroup()

io-ts-types are not referencing the new libs explicitly

My plan would be

• release fp-ts@1.0.0 (after (*))
• merge 1.0.0 io-ts#112 and release io-ts@1.0.0
• update all remaining libraries (inluded a cleaned up io-ts-types)

[gcanti]

UPDATE

I'm working on a bunch of PRs, the goal would be to coordinate all releases in one shot. Here's the dependencies

fp-ts (v1.0.0) -- io-ts (v1.0.0)
              \-- monocle-ts (v1.0.0)
                                    \-- newtype-ts (v0.2.0)
                                                           \-- io-ts-types (v0.3.0)

You can install the current candidates by running

• npm i gcanti/fp-ts#next
• npm i gcanti/io-ts#next (related PR here)
• npm i gcanti/monocle-ts#next (related PR here)
• npm i gcanti/newtype-ts#next (related PR here)
• npm i gcanti/io-ts-types#next (related PR here)

(for these kind of tests / quick feedback installing from github looks more practical than publishing on npm)

Let me know if you hit any issue

[sledorze]

Ok, got no issue so far (but was not able to test with your latest changes - aka type guards - as they've not been published yet).

[gcanti]

as they've not been published yet

@sledorze make sure to install fp-ts by running npm i gcanti/fp-ts#next (<= i.e. from GitHub not from npm)