Re: [Haskell-cafe] Re: Re: nested maybes
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. -- Mikael Johansson | To see the world in a grain of sand [EMAIL PROTECTED]| And heaven in a wild flower http://www.mikael.johanssons.org | To hold infinity in the palm of your hand | And eternity for an hour ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Re: nested maybes
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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Re: nested maybes
On Wed, 7 Feb 2007, Dan Weston wrote: 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? They probably would be -- which'd end up displaying the category (and thus the way I think about Haskell) as a quotient category of the Haskell98 category. I think though, still, that my argument carries content to the discussion: regardless of whether we handle currying or not (note that any function has a completely curried normal form) we still end up with the original argument separating things that doesn't necessarily make sense to separate -- in the argument 0-ary functions from n-ary functions. Dan -- Mikael Johansson | To see the world in a grain of sand [EMAIL PROTECTED]| And heaven in a wild flower http://www.mikael.johanssons.org | To hold infinity in the palm of your hand | And eternity for an hour ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Re: nested maybes
Mikael Johansson wrote: 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. Dan Weston wrote: This rather inconveniently clashes with the fact that A and () - A are two distinct types in Haskell. Not really. It's just that in the terminology of category theory, there is no direct way to talk about elements of an object. In general, objects do not need to be sets, so there is no notion of an element. In our case, where the objects - Haskell types - happen to be sets, we get our hands on elements of an object by using the trick of taking elements of the set of morphisms from () to the type. With functions, we have the opposite situation. Functions are first-class in Haskell. So for each function of type A - B there are two representations in the category: as an element of the object A-B, and as an element of the set of morphisms from A to B. I take it by your argument that curried and uncurried functions, being isomorphic, are represented by the same object in your category? No. (A,B)-C and A-B-C are two different types, so they are two different objects in the category. The two objects are isomorphic via curry and uncurry. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Re: nested maybes
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. Unix pipes also read from left to right, even though programs receive their arguments to the right of the program namen, and that feels totally natural. I'd say what 'feels natural' is in the eye of the beholder. One can get used to almost any form of convention, notational and otherwise, however inconsistent. For instance, the Haskell convention for (.) feels natural for me, because I have been doing math for a long time and mathematicians use the same convention. OTOH, the math convention also says that the type of a function is written (ArgType - ResultType), although (ResultType - ArgType) would have been more logical because consistent with the application order. I am used to it, so it feels natural to me, but does that make it the better choice? Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
