Add more directives for core libraries

[jam-awake]

Fixes #6. WIP.

I'm assuming that categorizing these directives by library will make it easier to determine whether we've fully audited that library.

[natefaubion]

Is there a justification for why you are adding the things you are adding? Some of them make sense to me, as they are combinators and it's helpful to inline to the more primitive call, but some of the dictionaries aren't clear to me. To be clear, I don't think it should be a goal to add an annotation for everything (this is unnecessary), but for things that are advantageous for optimizations.

[natefaubion]

Did you add all the const methods because they are essentially noops?

[natefaubion]

I think for things like this it might be better to use the new (..) syntax rather than inlining the dictionary directly.

[natefaubion]

Are there particular optimizations you are trying to trigger with these?

[jam-awake]

Is there a justification for why you are adding the things you are adding? Some of them make sense to me, as they are combinators and it's helpful to inline to the more primitive call, but some of the dictionaries aren't clear to me. To be clear, I don't think it should be a goal to add an annotation for everything (this is unnecessary), but for things that are advantageous for optimizations.

I figured I would at least get the PR started, even if it wasn't correct in various places. My methodology was just adding an inline directive for everything that had a type class constraint. I know that's not correct in various circumstances, but I don't have a clear understanding as to when it's desirable to add such a directive and when it's not.

This is my current understanding:

• for functions derived from type class instances / combinators with type class constraints (e.g. voidLeft, lmap, etc.), it is always desirable to add an inline directive because you'll get a more specialized version of that function.
• for primitive types with kind Type (e.g. String, Int), it's always desirable to add directives to their type class instances because those may trigger other optimizations
• for primitive types with higher kinds like Type -> Type (e.g. Array, Record), it's sometimes desirable to add directives to their type class instances because those may trigger other optimizations. But because the resulting dictionaries such instances define take other dictionaries as arguments, it may lead to code bloat in some situations.
• (based on your comments above about CatQueue). For data types that store other data types, it is generally undesirable to add directives to their type class instances as it may inline too much and bloat your code. Const is an exception to this because it ignores its arguments.

[natefaubion]

It sounds like you are wanting a consistent rule that you can apply to every definition based on it's type signature alone. Optimizations rely on the code that is generated (ie, the implementation). Sometimes things can have a simple signature, but inlining them doesn't result in anything interesting happening, and so you've just duplicated code to no effect. If you want to inline something, then yes, it's type signature can help you decide what directive to add, but the type signature alone does not tell you something is worth inlining. My recommendation is to not add a directive unless you have a specific desired result from that inlining. It is not interesting to inline something for the sake of inlining. Yes, this means that you can't just go through and add directives without observing the result. The original issues says:

We should assess if there are more things in core that would benefit users by being in the default set.

The question you have to answer is "is this beneficial?". If you aren't sure, then don't add it! This is why there are a bunch of "default rules" snapshots. They observe something practical happening from the default rules firing.

for functions derived from type class instances / combinators with type class constraints (e.g. voidLeft, lmap, etc.), it is always desirable to add an inline directive because you'll get a more specialized version of that function.

This is generally an alright rule, but no, there is no such thing as "always desirable" based on a type signature. These are generally good to inline because 1) they are often just an application of a more primitive form 2) they are usually small and don't contribute to code bloat.

for primitive types with kind Type (e.g. String, Int), it's always desirable to add directives to their type class instances because those may trigger other optimizations

No, this isn't really a rule I follow. What matters is if you can observe something beneficial happening by inlining them. It has nothing to do with the type.

for primitive types with higher kinds like Type -> Type (e.g. Array, Record), it's sometimes desirable to add directives to their type class instances because those may trigger other optimizations. But because the resulting dictionaries such instances define take other dictionaries as arguments, it may lead to code bloat in some situations.

The criteria for Record is that RowList metaprogramming is like a macro. it's pretty rare that RowList metaprogramming is not beneficial to inline because the structural induction gets flattened out to straightline code over record fields. But again, this has nothing to do with the type, and has to do with the code that gets generated. Regarding Array:

• eqArray doesn't contribute to code bloat because it's a foreign implementation. There's no reason not to inline the direct foreign binding. But again, this is because of the implementation.
• showArray is the same story. It's just a foreign implementation so no code bloat.

[jam-awake]

I think this is another primitive operation that should be evaluated.

[jam-awake]

I opened #34 to track this.

[jam-awake]

This is ... tedious 😄

I still need snapshots for the following, but I'll get to that next week:

• WriterT's MonadWriter usage
• RWST
• ListT
• ContT (this will be fun...)
• IdentityT

I'll likely skip the Comonad ones.

[jam-awake]

I've ported most of this code into #33. The current PR includes a lot of code for monad transformers, which revealed that more needs to be done to account for that (see above for comments). I've opened an issue to track the other issue I found for evaluating literal string comparisons.

Moreover, these might be annotations we shouldn't add to this project but leave it to end-users to do, especially with this project still being young.

[jam-awake]

The monad transformers work was extracted and put into the jam/monad-transformers branch