[Haskell-cafe] Systematic treatment of static arguments

[Stephen Tetley]

Hi Erik and wren

Thanks for both messages.

On 17 October 2010 10:12, Erik Hesselink <hesselink at gmail.com> wrote:
[Snip]
>
> I think you can just use the original instance for Monoid for this. It declares
>
> instance Monoid b => Monoid a -> b
>
> since 'b' can itself be a function (and r1 -> r2 -> a is parenthesized
> as r1 -> (r2 -> a)), this will work. 'b' can be instantiated to (r2 ->
> a) in your case, which is a Monoid due to another instance for
> functions, this time with 'b' instantiated to 'a'.

Thanks - it does work correctly, I was thinking it had to be (r1 -> r1
-> a), but (r1 -> r2 -> a) is fine too. Somewhere when I was
experimenting with GHCi, I must have misread an error message to make
me think I needed a new function mappendR2 for (r1 -> r2 -> a).

> This doesn't work for Reader, though. There, you're probably easier
> off using just a tuple, or, even better, a record, where you can use
> the 'asks' function to extract a single component.
>

I'm not sure about that one - using a record mandates the upfront work
of a record for each combination and then using Applicative or Monad
combinators with 'asks' for each operation. By extending the
combinator set I can avoid a lot of the clutter from 'asks' but the
downside is I'm introducing my own notation and naming system. Using a
tuple as wren also suggested would probably mean I'd likewise have to
make extensive use of tuple projection functions rather than 'asks'.

I think what I'd doing has similarities to Conal Elliott's 'semantic
editor combinators' so I'll investigate them again, although I feel
Conal's notation is too general for my purposes in this case. Conal
encodes a "path" directing what the lifted function operates on as
part of each "editor", because my "paths" are shorter and I have fewer
of them I'd prefer to encode them directly as named combinators.

Thanks again

Stephen