[Haskell-cafe] Re: Re: nested maybes

[Dan Weston]

 > A way to categorify elements of objects in a cartesian closed category
 > (such as that that sufficiently restricted Haskell takes place in) are
 > to view entities of type A as maps () -> A.Mikael Johansson wrote:

This rather inconveniently clashes with the fact that A and () -> A are 
two distinct types in Haskell. A is just the "curried" counterpart to () 
-> A, just as A -> B is the curried counterpart to OneTuple A -> B and A 
-> B -> C is the (fully) curried counterpart to (A,B) -> C

I take it by your argument that curried and uncurried functions, being 
isomorphic, are represented by the same object in your category?

Dan

> On Wed, 7 Feb 2007, Benjamin Franksen wrote:
>> Udo Stenzel wrote:
>>> Benjamin Franksen wrote:
>>>> Udo Stenzel wrote:
>>>>> Sure, you're right, everything flowing in the same direction is 
>>>>> usually
>>>>> nicer, and in central Europe, that order is from the left to the 
>>>>> right.
>>>>> What a shame that the Haskell gods chose to give the arguments to (.)
>>>>> and ($) the wrong order!
>>>>
>>>> But then application is in the wrong order, too. Do you really want to
>>>> write (x f) for f applied to x?
>>>
>>> No, doesn't follow.
>>
>> No? Your words: "everything flowing in the same direction".
>>
>> Of the two definitions
>>
>> (f . g) x = g (f x)
>>
>> vs.
>>
>> (f . g) x = f (g x)
>>
>> the first one (your prefered one) turns the natural applicative order
>> around, while the second one preserves it. Note this is an objective
>> argument and has nothing to do with how I feel about it.
>>
> 
> I would guess that one thing lying at the bottom of this particular 
> disagreement is whether everything is a function, or whether objects are 
> some qualified class of their own.
> 
> A way to categorify elements of objects in a cartesian closed category 
> (such as that that sufficiently restricted Haskell takes place in) are 
> to view entities of type A as maps () -> A. If this is the case, then 
> with g::A -> B and f:: B -> C, we would want our composition to work the 
> same way regardless of what we feed into it, and so we have two choices 
> of notation: either
> x . g . f
> or
> f . g . x
> (where I'm using the fact that composition in a category is associative, 
> as to not write the brackets everywhere)
> 
> Now, here it is perfectly obvious why Udo's argument applies, and that 
> inverting (.) and ($) would lead to (x f) meaning f applied to x. In a 
> way, this is more in agreement with the actual maps we view, since
> x . g . f
> corresponds to a composition
> () -> A -> B -> C ==> () -> C
> 
> However, if elements are to be viewed as something different entirely, 
> not in any way acquainted with functions, then one could state that 
> function composition should be by right action, and element application 
> by left action, so as to mimic the unix shell situation. It seems a bit 
> unnatural in purely functional languages though, and I believe that 
> one'd lose important intuition that way around.
>