J. Garrett Morris wrote:

Maybe has a Monad instance, so you can write this as follows (untested):

exists str wmap = boolFromMaybe exists' where exists' = do x <- Map.lookup (sort str) wmap find (== str) (snd x) boolFromMaybe (Just _) = True boolFromMaybe Nothing = False

Small improvement (Data.Maybe is underappreciated):

exists str wmap = isJust exists' where exists' = do x <- Map.lookup (sort str) wmap find (== str) (snd x)

and maybe another improvement, though this is dependent on your tastes:

exists s wmap = isJust $ Map.lookup (sort s) wmap >>= find (== s) . snd

-Udo -- Catproof is an oxymoron, childproof nearly so.

Hi

This is true. Some time ago I swore off the use of fromRight and fromLeft in favor of maybe, and have been forgetting about the other functions in Data.Maybe ever since.

I think you mean you swore off fromJust. Unfortunately when people started to debate adding fromLeft and fromRight they decided against logic and consistency, and chose not to add them... Thanks Neil

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? Ben

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

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.

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

On 2/5/07, Bulat Ziganshin wrote:

Hello J.,

Sunday, February 4, 2007, 11:46:57 PM, you wrote:

...

exists s wmap = isJust $ find (==s) . snd =<< Map.lookup (sort s) wmap

exists s wmap = Map.lookup (sort s) wmap >>== snd >>== find (==s) >>== isJust

a>>==b = a>>=return.b

Very nice! Didn't know about >>==. Thanks to everyone else who responded too; I'm learning a lot from this thread. martin

On 2/4/07, Martin Huschenbett wrote:

Hi,

I've often got the same pattern with nested Maybes but inside the IO monad (sure this could be every other monad too). Assuming that I've got functions:

This is where my favorite part of the mtl steps in: monad transformers. First, we'll create a transformed version of the IO monad, which encompasses the idea of failure. I've made the failures somewhat more general by allowing String typed error messages, but you can replace String with whatever type you'd like (including () if you really don't want any such information).

newtype MyIO a = MyIO { runMyIO :: ErrorT String IO a } deriving (Functor, Monad, MonadError String)

This uses GHC's newtype deriving mechanism, and thus requires -fglasgow-exts. The same effect can be achieved in Haskell 98 by using a type synonym instead of a newtype. Then, we need to have your operations produce their results in MyIO a instead of IO (Maybe a):

getInput :: MyIO Input processInput :: Input -> MyIO Result printError :: String -> MyIO () printResult :: Result -> MyIO ()

Finally, we can rewrite your main function without the case statements:

main = runErrorT . runMyIO $ (do input <- getInput result <- processInput input printResult result) `catchError` printError

However, in this case you don't really need do notation at all. You have a very nice pipeline of operations, and we can express it that way:

main' = runErrorT . runMyIO $ (getInput >>= processInput >>= printResult) `catchError` printError

which should remove the last vestiges of imperative-feeling code. /g -- It is myself I have never met, whose face is pasted on the underside of my mind.

On 2/5/07, Yitzchak Gale wrote:

J. Garrett Morris wrote:

...

First, we'll create a transformed version of the IO monad,

Why go to the trouble of creating a new monad? The existing ones are fine.

Mainly to keep the type error messages simpler. A project I was working on started with type S = StateT Blargh (ErrorT Fizzt IO) which was fine and dandy, although it produced somewhat verbose error messages. But then we added ContT to the stack, and the end result was that error messages tended to take more time giving the transformers than the errors. On the other hand, using a newtype the error messages were much easier to read. /g -- It is myself I have never met, whose face is pasted on the underside of my mind.

On 2/5/07, Yitzchak Gale wrote:

J. Garrett Morris wrote:

...

Mainly to keep the type error messages simpler.

There are two ways to get around that problem:

1. Make your functions polymorphic, using MonadState, MonadError, etc. Each function mentions only the capabilities that it needs, without having the whole monad stack in its type.

Again, from the earlier example, I'm not sure how typing: apply :: (MonadCont m, MonadState Blargh m, MonadError Fzzt m, MonadIO m) => Handle -> Attribute a -> m a is simpler than apply :: Handle -> Attribute a -> m a especially when almost every function in the project would have required the same constraint list.

2. Use a type alias for the monad stack.

At least as of 6.4.2, GHC printed the expanded types, not the aliases, in error messages.

(There are other big advantages of both of these.)

Those being? /g -- It is myself I have never met, whose face is pasted on the underside of my mind.

On 2/6/07, Yitzchak Gale wrote:

J. Garrett Morris wrote: Well, no, but it is at least no worse than

apply :: Handle -> Attribute a -> ContT (StateT Blargh (ErrorT Fzzt IO)) a

I find that in general, many functions do not need all of the capabilities. If they do, you can alias that also:

Well, in this case, the function looked more like: apply :: Handle -> Attribute a -> S a Part of the point here was that S was an abstraction. Most functions weren't accessing the state or the continuations directly - and their interaction with the error type had an intermediary as well. Instead, they were using operations that, in turn, used the underlying pieces.

You often need to make changes to the monad stack - add or remove capabilities, reorder, etc. This way, you only change the type in one place, and only fix functions that use the particular capabilities that were changed.

This is the same with my newtype-deriving alias.

The usual advantages of polymorphism apply - gives separation of concerns, encourages reuse, eases maintenance and testing, better expresses the meaning of the function by not mentioning unneeded details.

Well, we accomplished this all by having an abstraction barrier between a set of basic operations (which knew, at some level, about the internals of S and had their own sets of unit tests) and things built on top of S (which hypothetically could have gotten to its internals, but didn't. It would have been better practice to not export the instances, but I didn't think of that at the time_.

By the way, are you really doing CPS? If you are only using ContT to get short-circuiting, you could probably also simplify things by using ExitT instead:

We had a threading system which scheduled application threads to a limited number of IO threads based on data-driven changing priorities. This was first designed for GHC 6.2.2, when the threaded runtime wasn't in the shipping versions yet. I really think we're just talking about two approaches to the same thing. I prefer to encapsulate most of the MonadX operations as soon as possible behind a domain-specific layer, and then write the rest of my code in terms of that. In that case, I get isolation of concerns and testing and such from the fact that the internals of the monad stack aren't exposed, and if they need to be changed it only affects the DSL components, not the majority of the code. /g -- It is myself I have never met, whose face is pasted on the underside of my mind.