[Haskell] method annotations

[John Meacham]

On Sat, Mar 03, 2007 at 08:23:08AM -0500, Isaac Dupree wrote:
> Unfortunately it would be difficult for the compiler to know that no-one
> is going to make an instance that does depend on its argument (as long
> as it does not do full-program analysis to determine the layout of data
> structures). Maybe there should be some sort of annotation on class
> method arguments that are supposed to be ignored, even if only a pragma,
> if it would help compilers figure this out.

indeed, I have given this some thought too, but not just for whether a
type will be unused. my current thinking is something like

> class Bits a where
>         shift :: a -> !Int -> a
> 
> class Eq a where
>         (==) :: a -> a -> !Bool
> 
> class Typeable a where
>         getType :: ~a -> TypeRep

where '!Int' means that the class is strict in the Int argument. and ~
means it is unused. 

note, these are not just hints, but actually affect the class
translation.

shift as above would translate to something ilke

> shift :: BitsDict a -> Int -> a 
> shift bd x i = i `seq` shiftInstance bd x i

where shiftInstance selects the appropriate value from the dictionary

of course, the real benefit is now that we can do unboxing on class
methods!

we can treat the above class declaration as if it were

class Bits a where
        shift :: a -> Int# -> a

safely and rewrite instance declarations appropriately


likewise, the ! on the return value in Eq means that we should unbox it.
(this is actually always safe, so perhaps a pragma will do for this,
"UNPACK" seems appropriate)


for the other case

> class Typeable a where
>         getType :: ~a -> TypeRep

would create a method like so

> getType :: TypeableDict a -> a -> TypeRep
> getType td a = getTypeInstance td (undefined `asTypeOf` a)


which causes getType to always throw away its argument, allowing the
compiler to make assumptions based on it.




another implicit optimization that is going on in my translations above is
eta-expansion of the class methods (which is independent of the
optimizations given above). this is potentially unsafe, but I have been
performing the optimization in jhc without ill effect and with noticable
benefit. however, you can specify the "NOETA" pragma in order to
suppress this auto-eta-expansion as it does decrease sharing.

another option for controlling eta expansion would be something like

class Eq a where
        (==) :: a -> !(a -> Bool)

which makes explicit that the partial result of (==) applied to one
argument could usefully be shared.

currently, these optimization are availabe in jhc, but only via pragmas
and some built in heuristics/special knowledge in the compiler. 
Implementing the above syntax has been on my todo list. Anecdotal
examination of core leads me to believe they could be signifigantly
beneficial.

        John


-- 
John Meacham - ⑆repetae.net⑆john⑈