add INLINEABLE to maybe, either, bool

[Ian Lynagh]

On Tue, Sep 17, 2013 at 10:27:23AM -0700, Dan Burton wrote:
> 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?

1. Having type sigs means that you get better type errors.

2. Having type sigs makes it easier for developers to work out what a
   function does and how to use it.

3. Having type signatures means that you get an error if the compiler
   doesn't agree with you.

None of these apply to INLINE pragmas.

To get something similar you'd need an INLINED pragma, where
    {-# INLINED f #-}
    f = ...
would be a compilation error if the compiler didn't decide that f should
get an unfolding. (I'm not seriously proposing this pragma).

> 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,

INLINED would be a sanity check. INLINE is an instruction.

> If someone reads through the source, and wonders whether "bool"
> will be inlined

The purpose of writing an optimising compiler is so that we can, for the
most part, leave it alone to optimise our programs.


Thanks
Ian