type-level definitions naming

[Edward Kmett]

>
>
>
> On Mon, Oct 21, 2013 at 6:04 AM, Richard Eisenberg <eir at cis.upenn.edu>wrote:
>
>> - There is a new function (in Data.Type.Equality) gcastWith :: (a :~: b)
>> -> ((a ~ b) => r) -> r. Type inference for this function works well.
>>
>
> In my experience, for partial application it's convenient to have the
> arguments the other way around.
>
>
> I'd be worried about type inference with partial application and reversed
> parameters. The values of a and b can only be gleaned from the equality
> witness, so I would think that delaying that parameter would cause some
> havoc. Is that not what you've seen?
>
>
I use the alternate order in (\\) for the constraints package and have had
no issues with it after "using it in anger" for a couple of years now.

- I've renamed EqualityT and CoercionT to EqualityType and CoercionType.
>> The T's at the ends of the old names made me think of monad transformers. I
>> don't like the new names, though.
>>
>
> No radically better ideas, but perhaps marginally: `TypeEq` and
> `TypeReprEq`? Or `TestEquality` and `TestCoercible`?
>
>
Out of those alternatives I rather prefer TestEquality and TestCoercible
over randomly introducing unrelated abbreviations. =/

-Edward

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131022/8535135b/attachment.html>