Coverage decreased (-1.7%) to 55.819% when pulling 05caeea on jutaro:master into 7174a75 on purescript:master.

I really hate to add noise but I would love to be able to use this!

@Filib For now I recommend building from @jutaro's branch if you need this optimization.

I would like to think about more optimizations generally after 1.0, including general inlining on the functional core output, but for now, I don't want to commit to a certain specific optimization in master. I'm also not sure what the long term fate of psc-bundle and the use of language-javascript will be, in light of the recent changes to dump the functional core.

@phil, we had a conversation about this recently. As you see it's tiresome
to update my branch now for more then half a year.
Why not integrate the optimization (and drop it if something better is
coming - I will be happy then).

Where can I learn what "the recent changes to dump the functional core"
means?

2016-10-12 18:51 GMT+02:00 Phil Freeman notifications@github.com:

@Filib https://github.com/filib For now I recommend building from
@jutaro https://github.com/jutaro's branch if you need this
optimization.

I would like to think about more optimizations generally after 1.0,
including general inlining on the functional core output, but for now, I
don't want to commit to a certain specific optimization in master. I'm
also not sure what the long term fate of psc-bundle and the use of
language-javascript will be, in light of the recent changes to dump the
functional core.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#2219 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAlqz8Jt8jRMKIP3XiYaN8ZxMOIvUEM2ks5qzRAtgaJpZM4JF0C8
.

As you see it's tiresome to update my branch now for more then half a year.
Why not integrate the optimization (and drop it if something better is coming - I will be happy then).

I'm sorry that you find it tiresome. Others have worked on alternative backends have been maintaining forks for years in some cases, but I don't want to merge in changes which are not in the plan for 1.0 and which we might remove later. Also, there are no tests or documentation.

Where can I learn what "the recent changes to dump the functional core"
means?

Here is the PR which was merged recently: #2275, and the issue which it was based on: #876.

@paf31

I'm also not sure what the long term fate of psc-bundle and the use of language-javascript will be, in light of the recent changes to dump the functional core.

Are you suggesting that we might want to consider an uncurrying optimization operating on the core functional representation instead of the JS representation? I guess the core functional representation is going to be simpler than a JS AST so that seems like a good idea, and also, presumably, that would mean that other backends could benefit from it, not just the JS backend?

I think if we were going to do that it would probably be better to do so on the imperative core. CoreFn only has one argument functions and I think it should stay that way personally.

I'll work on reviving CoreImp soon actually. It was pretty much done at one point, I had just been working on moving all of the optimisations that could applied to it, but I guess that's not a requirement, we could still do them on the JS at first and move them over piecemeal once CoreImp is merged.

As noted above, this needs (lots of) discussion before we decide how to handle optimization during bundling, or if we want to do it there at all. My preference is to use the corefn output as the target for this sort of optimization, and I don't want to add more code to purs bundle which might be removed later at this point.

I'm going through and closing PRs which aren't in line with plans for 1.0. Thanks @jutaro and @mgmeier for taking the initiative here, and I'm sorry it didn't work out. I hope you find a place for this optimization elsewhere, either in a fork or as a corefn pass.