[haskell-llvm] llvm-patch: Generalise the CallArgs type class so you can use call with two return types within one module

[Henning Thielemann]

On Wed, 6 Jul 2011, Max Bolingbroke wrote:

> If you check bos's commit history you will see that it is his practice
> to bump version just before a release. For example, the current
> Hackage version was released on May 19th
> (http://hackage.haskell.org/package/llvm) and the corresponding commit
> on May 19th includes a version number bump to the released version
> (https://github.com/bos/llvm/commit/a5176f87931dfbcb3355f62e67ed4a25e345db2e).

Hm, then I propose to change that style.


> RE swapping the arguments to CallArgs, I can do this. However,
> CallArgs and FunctionArgs do not seem to be entirely analogous. We
> have:
>
> class CallArgs f g r | g -> r f, f r -> g where
> class FunctionArgs f g r | f -> g r, g r -> f where
>
> Note that the parameters f and g occur in the functional dependencies
> in precisely opposite senses in these classes. So if we were slavish
> about consistency we might be tempted to swap these two parameters as
> well.

In both cases f is the IO function and g the CodeGenFunction, so in this 
respect they are consistent. However, the 'r' of FunctionArgs is not a 
return type, but also a CodeGenFunction. I currently do not really 
understand, why FunctionArgs is defined the way it is, but according to 
the comments the original author also seems not to be satisfied with it.

> There is also precedence for "r" first in the definition of
> CodeGenFunction (in this case because it must be a monad in the right
> way):
>
> newtype CodeGenFunction r a
>
> Nonetheless, I have submitted a patch for the "r" parameter change to bos.

I am also happy with swapping the parameter order of FunctionArgs.
Maybe we can also simplify it in the way that the original author thought 
of.