Use EffectFnX functions internally

[hdgarrood]

To prevent issues like #27 from occurring again.

[paf31]

👍

[artemisSystem]

From what i can tell, this issue is about using (what's now called) Effect.Uncurried (EffectFnX) instead of FnX and mkEffect. The use of mkEffect prevents things like #27 by my understanding, but it's still an old and convoluted way of doing things. Perhaps we could switch over to EffectFnX at the same time as changes for #19 are made.

[JordanMartinez]

I was thinking the same thing when I reviewed your other PR. We should be using EffectFnX now.

[hdgarrood]

My intention when I created this was only to change the implementations internally, not to change the type signatures of any exported functions - I don't think we should use EffectFn in the exported functions in this library.

[artemisSystem]

Agreed

[colinwahl]

I ran into a case where the current unsafe mkEffect util causes a runtime error when running this code through purescript-backend-optimizer. There is some discussion on why: aristanetworks/purescript-backend-optimizer#29

I'd be happy to make this change if no one else is working on it at the moment.

[JordanMartinez]

I'm in agreement with making this breaking change to this library outside of the normal ecosystem breakage. With the advent of purs-backend-es, some things can't be optimized without this.

@colinwahl Go for it!

[colinwahl]

This shouldn't be a breaking change - none of the values whose types are changing are exported, and the exported values all retain their same types.

[JordanMartinez]

This shouldn't be a breaking change - none of the values whose types are changing are exported, and the exported values all retain their same types.

Oh nice! I wasn't aware of that.