add INLINEABLE to maybe, either, bool

[Dan Burton]

I again want to emphasize how we can view INLINE annotations much the same
way as type annotations. It is considered good practice to annotate
top-level definitions with type signatures. Why? Is it because the compiler
can't figure it out? Is it because the programmer doesn't trust the
compiler to figure it out? No, it's because it is a visible, enforced
sanity check to make sure that the programmer and the compiler are on the
same page, regardless of any magic the compiler is capable of. (I like the
various ideas that are being thrown around about "asserting" that something
will be inlined.)

I see superfluous INLINE pragmas as for the benefit of humans, allowing
them to express their desires explicitly, rather than relying on implicit
behavior that is hard for the average muggle to understand, verify, or
guarantee. If someone reads through the source, and wonders whether "bool"
will be inlined, they don't need to know any details about the current
state of the inliner algorithm when they can just see the pragma right
there in the source.

The inliner should be at the whim of its masters, the humans, not the other
way around.


-- Dan Burton


On Tue, Sep 17, 2013 at 6:11 AM, Roman Cheplyaka <roma at ro-che.info> wrote:

> Austin,
>
> First of all, let me say that I am generally on the same side of this
> argument as you are now.
>
> But Dan raised very good and valid points, and I don't think you
> addressed them directly (quotations follow):
>
> 1. If you want to test the auto-inliner's wisdom, then just add a
>    setting that ignores INLINE pragmas and see if it inlines the same
>    thing that humans do?
> 2. I don't really care how it's accomplished, but I do think that we should
>    make sure that maybe, either, and bool are inlined, and the most obvious
>    way to accomplish this is to directly mark them INLINE, is it not?
>
> Roman
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131011/3eefe00f/attachment.html>