Please describe shortly the project objectives

[paluh]

• Could you please describe shortly what is the general plan for this project?

• What is the input and what is the possible output which you want to produce - is it CoreFn -> CoreFn transformation?

• I wonder if this project could be ported/migrated to PS. Optimizing PS in PS could be a nice feedback loop I think. Do you see any significant obstacles? Do you think that CoreFn precise enough to be a base for things like specialisation etc.?

[natefaubion]

My goal for this project would be:

Perform whole-program optimization. The current compiler optimizations are plenty good enough for development. I would like an option to have aggressive whole-program optimizations. This might include uncurrying or any other global usage-based optimizations.

Subsume optimizations that are only performed on the CoreImp representation currently. This will include potentially extending the core representation with additional forms:

• N-ary functions and function applications, which will let us represent uncurrying, mkFn, Effect, etc.
• Join points, which will let us represent local jumps for pattern-matching optimizations and TCO.
• Primitive effects which would be trivially inlined by codegen for things like ST and Refs.

Inlining and partial evaluation. Especially with regard to monomorphic type-class dispatch. I would also like to build in support for more primitive things like Data.Record.Builder. My goal would be for "generic-like" (Generic.Rep, heterogeneous) workflows to be zero or very low cost.

Non-goals:

• Operate on CoreFn directly. I don't think CoreFn is expressive enough for more general optimizations. I think you'd just be extending it in an ad-hoc way with annotations and magic calls. I would prefer to use an internal IR that better represents the optimizations we would want to do. I've started this with CoreAnf. Whether that is ideal or not, I don't know.
• Self-optimizing. The type of workflow for this optimizer is not representative of most PureScript programs, so I'm not convinced that writing it in PureScript is inherently beneficial. Aggressive optimizers can get slow even in compiled programs, so I don't really want to start off with what I consider to be a disadvantage. Haskell really is ideal for this kind of tooling. I'm not saying it isn't a possibility at some point, but you will very likely be dealing with order-of-magnitude performance loss.

[paluh]

Thanks! This plan looks amazing and I think that could be put directly into the README :-)

What kind of output are you going to spit out? Only JS? Something like CoreImp?

[natefaubion]

CoreImp is essentially a slightly simplified JavaScript. If the goal is to subsume CoreImp optimizations, then the only reason to output CoreImp is to reuse the existing compiler's printer. I would like to experiment with translating join-points to labeled loops and break/continue, which I don't think is currently possible with CoreImp.

You could translate back into CoreFn. This would be lossy and would involve undoing or prohibiting some optimizations, but it would be easier for some backend to just consume the results of the inliner.

I would probably make the IR consumable by other tools, and also provide a way to write out JS directly since that is the most common backend.

[natefaubion]

This plan looks amazing and I think that could be put directly into the README

I don't think it's worthwhile laying out the direction of it until some direction has been established in code. Right now this is all vaporware.

[paluh]

I don't think it's worthwhile laying out the direction of it until some direction has been established in code. Right now this is all vaporware.

So thanks for the info. Should I close it or leave open for reference?