fix stack issue for listT map

[safareli]

fix #16

[safareli]

JS from purescript 0.12 output was this:

var listTFunctor = function (dictMonad) {
    return new Data_Functor.Functor(function (f) {
        return function ($161) {
          var $160 = Control_Monad.liftM1(dictMonad)(bimapTStep(f)(Data_Functor.map(listTFunctor(dictMonad))(f)));
            return ListT($160(stepListT($161)));
        };
    });
};

but on purescript 0.13 output was changed to this:

var listTFunctor = function (dictMonad) {
    return new Data_Functor.Functor(function (f) {
        var $160 = Control_Monad.liftM1(dictMonad)(bimapTStep(f)(Data_Functor.map(listTFunctor(dictMonad))(f)));
        return function ($161) {
            return ListT($160(stepListT($161)));
        };
    });
};
\

With the change from this PR, js output on purescript 0.13 now looks like this:

var listTFunctor = function (dictMonad) {
    return new Data_Functor.Functor(function (f) {
        return function (v) {
            return ListT(Control_Monad.liftM1(dictMonad)(bimapTStep(f)(Data_Functor.map(listTFunctor(dictMonad))(f)))(stepListT(v)));
        };
    });
};


And it fixed the issue.

[safareli]

https://github.com/f-o-a-m/purescript-optparse/releases/tag/v3.0.1

[safareli]

https://github.com/purescript/purescript/releases/tag/v0.13.0 under “Other Changes > Breaking”
Fix sharing in function composition inlining (purescript/purescript#3439). This is really a bugfix, but it has the potential to break code. Previously, you could write recursive point-free compositions that the compiler inadvertently eta-expanded into working code by eliminating sharing. We've changed the optimization to respect strict evaluation semantics, which can cause existing code to stack overflow. This generally arises in instance definitions. Unfortunately, we don't have a way to disallow the problematic code at this time.