My understanding was that bind historically referred to `(=<<)`, not `(>>=)` Either way I am (+1) on this, even if my previous sentence is false. On 12/9/14, 1:55 PM, David Feuer wrote:

On Dec 9, 2014 4:44 PM, "Christopher Done" mailto:chrisdone@gmail.com> wrote:

...

The name for this function is a no-brainer:

bind :: Monad m => (a -> m b) -> m a -> m b bind = (=<<)

Since most people use the term "bind" to refer to the >>= operator, this would be very confusing.

...

For comparison, the not-very-pleasant <$> and <*> each have word alternatives, fmap and ap. Even <> has mappend.

fmap predates <$>, and <$> tends to be used only in certain contexts. "ap" has a narrower type than <*>.

...

I don't hold much hope for this, Haskellers love operators as much as Perl programmers so few on this list will see the value in plain old words, but at least I can link to this email in the archives for future reference.

I have nothing against the idea in principle, but that name won't fly.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

If there is a bindIO as specialization of (>>=), having a bind as alias for (=<<) is a bad idea. In category theory (Kleisli triple), (=<<) is called the extension operator. Most of my uses of (=<<) are infix, as a monadic application operator, so I never felt the need to have a non-operator version of it. Haskell is all about saving parentheses and being not Scheme, so f a =<< g b is definitely preferable over bind (f a) (g b) ;-) Cheers, Andreas On 10.12.2014 00:35, David Feuer wrote:

It's possible I got confused by GHC.Base, which defines

bindIO :: IO a -> (a -> IO b) -> IO b

If that's backwards, then go right ahead and use bind to mean (=<<).

On Tue, Dec 9, 2014 at 6:17 PM, Gabriel Gonzalez mailto:gabriel439@gmail.com> wrote:

My understanding was that bind historically referred to `(=<<)`, not `(>>=)`

Either way I am (+1) on this, even if my previous sentence is false.

On 12/9/14, 1:55 PM, David Feuer wrote:

...

On Dec 9, 2014 4:44 PM, "Christopher Done" mailto:chrisdone@gmail.com> wrote: > The name for this function is a no-brainer: > > bind :: Monad m => (a -> m b) -> m a -> m b > bind = (=<<)

Since most people use the term "bind" to refer to the >>= operator, this would be very confusing.

> For comparison, the not-very-pleasant <$> and <*> each have word > alternatives, fmap and ap. Even <> has mappend.

fmap predates <$>, and <$> tends to be used only in certain contexts. "ap" has a narrower type than <*>.

> I don’t hold much hope for this, Haskellers love operators as much as > Perl programmers so few on this list will see the value in plain old > words, but at least I can link to this email in the archives for > future reference.

I have nothing against the idea in principle, but that name won't fly.

_______________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel@gu.se http://www2.tcs.ifi.lmu.de/~abel/

I should mention that LYAH, in http://learnyouahaskell.com/a-fistful-of-monads , says The >>= function is pronounced as bind. RWH, in, http://book.realworldhaskell.org/read/monads.html , indicates Here, (>>=) is our chaining function. [...] It's often referred to as “bind”, as it binds the result of the computation on the left to the parameter of the one on the right. A Gentle Introduction to Haskell, at https://www.haskell.org/tutorial/monads.html , says The Monad class defines two basic operators: >>= (bind) and return. http://en.wikibooks.org/wiki/Haskell/Understanding_monads#Definition says an operator (>>=) which is pronounced "bind". In case it's not clear yet, I am firmly against using the name "bind" to mean (=<<). On Tue, Dec 9, 2014 at 10:24 PM, Felipe Lessa wrote:

I'm not sure what Abel's vote is, but I'm -1 on this proposal precisely because of the issues he explained below.

Cheers,

On 09-12-2014 23:44, Andreas Abel wrote:

...

If there is a bindIO as specialization of (>>=), having a bind as alias for (=<<) is a bad idea.

In category theory (Kleisli triple), (=<<) is called the extension operator.

Most of my uses of (=<<) are infix, as a monadic application operator, so I never felt the need to have a non-operator version of it.

Haskell is all about saving parentheses and being not Scheme, so

f a =<< g b

is definitely preferable over

bind (f a) (g b)

;-)

Cheers, Andreas

On 10.12.2014 00:35, David Feuer wrote:

...

It's possible I got confused by GHC.Base, which defines

bindIO :: IO a -> (a -> IO b) -> IO b

If that's backwards, then go right ahead and use bind to mean (=<<).

On Tue, Dec 9, 2014 at 6:17 PM, Gabriel Gonzalez mailto:gabriel439@gmail.com> wrote:

My understanding was that bind historically referred to `(=<<)`, not `(>>=)`

Either way I am (+1) on this, even if my previous sentence is false.

On 12/9/14, 1:55 PM, David Feuer wrote:

...

On Dec 9, 2014 4:44 PM, "Christopher Done" mailto:chrisdone@gmail.com> wrote: > The name for this function is a no-brainer: > > bind :: Monad m => (a -> m b) -> m a -> m b > bind = (=<<)

Since most people use the term "bind" to refer to the >>= operator, this would be very confusing.

> For comparison, the not-very-pleasant <$> and <*> each have word > alternatives, fmap and ap. Even <> has mappend.

fmap predates <$>, and <$> tends to be used only in certain contexts. "ap" has a narrower type than <*>.

> I don’t hold much hope for this, Haskellers love operators as much as > Perl programmers so few on this list will see the value in plain old > words, but at least I can link to this email in the archives for > future reference.

I have nothing against the idea in principle, but that name won't fly.

_______________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Felipe.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Possible names would be applyM, appM :: Monad m => (a -> m b) -> m a -> m b because this is an application function, albeit on a monadic value. Cheers, Andreas On 10.12.2014 04:44, David Feuer wrote:

I should mention that LYAH, in http://learnyouahaskell.com/a-fistful-of-monads , says

The >>= function is pronounced as bind.

RWH, in, http://book.realworldhaskell.org/read/monads.html , indicates

Here, (>>=) is our chaining function. [...] It's often referred to as “bind”, as it binds the result of the computation on the left to the parameter of the one on the right.

A Gentle Introduction to Haskell, at https://www.haskell.org/tutorial/monads.html , says

The Monad class defines two basic operators: >>= (bind) and return.

http://en.wikibooks.org/wiki/Haskell/Understanding_monads#Definition says

an operator (>>=) which is pronounced "bind".

In case it's not clear yet, I am firmly against using the name "bind" to mean (=<<).

On Tue, Dec 9, 2014 at 10:24 PM, Felipe Lessa wrote:

...

I'm not sure what Abel's vote is, but I'm -1 on this proposal precisely because of the issues he explained below.

Cheers,

On 09-12-2014 23:44, Andreas Abel wrote:

...

If there is a bindIO as specialization of (>>=), having a bind as alias for (=<<) is a bad idea.

In category theory (Kleisli triple), (=<<) is called the extension operator.

Most of my uses of (=<<) are infix, as a monadic application operator, so I never felt the need to have a non-operator version of it.

Haskell is all about saving parentheses and being not Scheme, so

f a =<< g b

is definitely preferable over

bind (f a) (g b)

;-)

Cheers, Andreas

On 10.12.2014 00:35, David Feuer wrote:

...

It's possible I got confused by GHC.Base, which defines

bindIO :: IO a -> (a -> IO b) -> IO b

If that's backwards, then go right ahead and use bind to mean (=<<).

On Tue, Dec 9, 2014 at 6:17 PM, Gabriel Gonzalez mailto:gabriel439@gmail.com> wrote:

My understanding was that bind historically referred to `(=<<)`, not `(>>=)`

Either way I am (+1) on this, even if my previous sentence is false.

On 12/9/14, 1:55 PM, David Feuer wrote:

...

On Dec 9, 2014 4:44 PM, "Christopher Done" mailto:chrisdone@gmail.com> wrote: > The name for this function is a no-brainer: > > bind :: Monad m => (a -> m b) -> m a -> m b > bind = (=<<)

Since most people use the term "bind" to refer to the >>= operator, this would be very confusing.

> For comparison, the not-very-pleasant <$> and <*> each have word > alternatives, fmap and ap. Even <> has mappend.

fmap predates <$>, and <$> tends to be used only in certain contexts. "ap" has a narrower type than <*>.

> I don’t hold much hope for this, Haskellers love operators as much as > Perl programmers so few on this list will see the value in plain old > words, but at least I can link to this email in the archives for > future reference.

I have nothing against the idea in principle, but that name won't fly.

_______________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Felipe.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel@gu.se http://www2.tcs.ifi.lmu.de/~abel/

I'd love to have a "bind" with that nice symmetry with fmap for both personal use and for pedagogical purposes. I use precisely that function by that name to help teach monads already. On Tue, Dec 9, 2014 at 3:55 PM, Bob Ippolito wrote:

+1 from me, I would love to have named versions of these operators.

Does `ap` still have a Monad constraint or has it been changed to match the Applicative `<*>` after AMP?

On Tue, Dec 9, 2014 at 1:44 PM, Christopher Done wrote:

...

Is this defined anywhere in base, and if not could it be placed in Control.Monad? I often find myself writing:

fmap (mu bar) (foo zot)

Then I decide to change the type of x, so instead I want to just write:

bind (mu bar) (foo zot)

Which is just like fmap but the function can run in the monad. Similar to traverse:

(Traversable t, Applicative f) => (a -> f b) -> t a -> f (t b)

As someone who isn’t a fan of operators, I generally am appreciative of alternative regular plain English word versions of functions, which I find easier to type, read and edit. Currently without defining such a handy name, I have to transform the code to this:

mu bar =<

The name for this function is a no-brainer:

bind :: Monad m => (a -> m b) -> m a -> m bbind = (=<<)

For comparison, the not-very-pleasant <$> and <*> each have word alternatives, fmap and ap. Even <> has mappend.

I don’t hold much hope for this, Haskellers love operators as much as Perl programmers so few on this list will see the value in plain old words, but at least I can link to this email in the archives for future reference.

Ciao ​

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

I’m +1 on this. Not only is it nice to sometimes have a non-operator (>>=) but it’s nice to have a function which more obviously lifts Kleisli arrows to monad arrows. Since it’s all aesthetics here, I think `bind f` is nice. Bob, ap is useful with the Monad constraint because it lets you define (<*>) just using an already written Monad instance. It looks like it’s staying that way too https://github.com/ghc/ghc/blob/master/libraries/base/GHC/Base.hs#L603 On Tue, Dec 9, 2014 at 4:55 PM, Bob Ippolito wrote:

+1 from me, I would love to have named versions of these operators. Does `ap` still have a Monad constraint or has it been changed to match the Applicative `<*>` after AMP? On Tue, Dec 9, 2014 at 1:44 PM, Christopher Done wrote:

...

Is this defined anywhere in base, and if not could it be placed in Control.Monad? I often find myself writing:

fmap (mu bar) (foo zot)

Then I decide to change the type of x, so instead I want to just write:

bind (mu bar) (foo zot)

Which is just like fmap but the function can run in the monad. Similar to traverse:

(Traversable t, Applicative f) => (a -> f b) -> t a -> f (t b)

As someone who isn’t a fan of operators, I generally am appreciative of alternative regular plain English word versions of functions, which I find easier to type, read and edit. Currently without defining such a handy name, I have to transform the code to this:

mu bar =<

The name for this function is a no-brainer:

bind :: Monad m => (a -> m b) -> m a -> m bbind = (=<<)

For comparison, the not-very-pleasant <$> and <*> each have word alternatives, fmap and ap. Even <> has mappend.

I don’t hold much hope for this, Haskellers love operators as much as Perl programmers so few on this list will see the value in plain old words, but at least I can link to this email in the archives for future reference.

Ciao ​

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

I'm +1 on joinMap. On Tue, Dec 9, 2014 at 10:57 PM, Niklas Haas wrote:

Possible name:

joinMap :: Monad m => (a -> m b) -> m a -> m b corresponds to concatMap :: (a -> [b]) -> [a] -> [b] _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

I’ll clarify my earlier note: I’m +1 on the idea alone. The name bind seems contestable (so -1) and I feel ~0 on joinMap. It sounds a bit too much like flatMap which I really dislike, although it’s at least much more accurate. On Wed, Dec 10, 2014 at 11:02 AM, David Feuer wrote:

joinMap looks to me like the best name, because it does just what it says on the box: join . fmap f $ m = (m >>= return . f) >>= id --Functor/Monad law = m >>= (\x -> return (f x) >>= id) --associativity = m >>= (\x -> f x) --left identity = m >>= f --eta reduction = f =<< m Christopher Done writes:

...

Is this defined anywhere in base, and if not could it be placed in Control.Monad? I often find myself writing:

fmap (mu bar) (foo zot)

Then I decide to change the type of x, so instead I want to just write:

bind (mu bar) (foo zot)

Which is just like fmap but the function can run in the monad. Similar to traverse:

(Traversable t, Applicative f) => (a -> f b) -> t a -> f (t b)

As someone who isn’t a fan of operators, I generally am appreciative of alternative regular plain English word versions of functions, which I find easier to type, read and edit. Currently without defining such a handy name, I have to transform the code to this:

mu bar =<

The name for this function is a no-brainer:

bind :: Monad m => (a -> m b) -> m a -> m bbind = (=<<) I'm -1 on the *name* `bind`, because as others have mentioned, I feel bind has the same type as (>>=). That said, I'm +1 on the *idea* - if we can find a better name. `joinMap` doesn't seem too bad, as was recently suggested, but I'll settle on anything other than `bind` -- ocharles

---

Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On 10.12.2014 17:33, John Lato wrote:

I don't really understand why people want this. What's wrong with (=<<) ? I kind of feel like a named function should be no longer than that.

You are right, we do not need a alphabetic version of every operator. We do not have plus = (+) either. Why take another good name from the user, just to avoid using an operator in parentheses? I am -1 on the whole business here. Cheers, Andreas

I don't object, especially if others think it's useful (and many clearly do), but I guess it's not to my taste.

On 08:02, Wed, Dec 10, 2014 David Feuer mailto:david.feuer@gmail.com> wrote:

joinMap looks to me like the best name, because it does just what it says on the box:

join . fmap f $ m = (m >>= return . f) >>= id --Functor/Monad law = m >>= (\x -> return (f x) >>= id) --associativity = m >>= (\x -> f x) --left identity = m >>= f --eta reduction = f =<< m

Christopher Done mailto:chrisdone@gmail.com> writes:

> Is this defined anywhere in base, and if not could it be placed in > Control.Monad? I often find myself writing: > > fmap (mu bar) > (foo zot) > > Then I decide to change the type of x, so instead I want to just > write: > > bind (mu bar) > (foo zot) > > Which is just like fmap but the function can run in the > monad. Similar to traverse: > > (Traversable t, Applicative f) => (a -> f b) -> t a -> f (t b) > > As someone who isn’t a fan of operators, I generally am appreciative > of alternative regular plain English word versions of functions, which > I find easier to type, read and edit. Currently without defining such > a handy name, I have to transform the code to this: > > mu bar =<<foo zot > > The name for this function is a no-brainer: > > bind :: Monad m => (a -> m b) -> m a -> m bbind = (=<<)

I'm -1 on the *name* `bind`, because as others have mentioned, I feel bind has the same type as (>>=).

That said, I'm +1 on the *idea* - if we can find a better name. `joinMap` doesn't seem too bad, as was recently suggested, but I'll settle on anything other than `bind`

-- ocharles

_______________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_________________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org http://www.haskell.org/__mailman/listinfo/libraries http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel@gu.se http://www2.tcs.ifi.lmu.de/~abel/

On Wed, Dec 10, 2014 at 8:43 AM, Andreas Abel wrote:

On 10.12.2014 17:33, John Lato wrote:

...

I don't really understand why people want this. What's wrong with (=<<) ? I kind of feel like a named function should be no longer than that.

You are right, we do not need a alphabetic version of every operator. We do not have

plus = (+)

either. Why take another good name from the user, just to avoid using an operator in parentheses?

As a default rule, I think every operator should have a named function. This is because symbols have no inherit meaning, but words do. Math is the exception to the rule. Basic math is universal: someone coming from any background will immediately recognize (+), (-), etc. Monad operators only seem universal once you have been programming Haskell for several years :)

I am -1 on the whole business here.

Cheers, Andreas

...

I don't object, especially if others think it's useful (and many clearly do), but I guess it's not to my taste.

On 08:02, Wed, Dec 10, 2014 David Feuer mailto:david.feuer@gmail.com> wrote:

joinMap looks to me like the best name, because it does just what it says on the box:

join . fmap f $ m = (m >>= return . f) >>= id --Functor/Monad law = m >>= (\x -> return (f x) >>= id) --associativity = m >>= (\x -> f x) --left identity = m >>= f --eta reduction = f =<< m

Christopher Done mailto:chrisdone@gmail.com>

writes:

> Is this defined anywhere in base, and if not could it be placed in > Control.Monad? I often find myself writing: > > fmap (mu bar) > (foo zot) > > Then I decide to change the type of x, so instead I want to just > write: > > bind (mu bar) > (foo zot) > > Which is just like fmap but the function can run in the > monad. Similar to traverse: > > (Traversable t, Applicative f) => (a -> f b) -> t a -> f (t b) > > As someone who isn’t a fan of operators, I generally am appreciative > of alternative regular plain English word versions of functions, which > I find easier to type, read and edit. Currently without defining such > a handy name, I have to transform the code to this: > > mu bar =<<foo zot > > The name for this function is a no-brainer: > > bind :: Monad m => (a -> m b) -> m a -> m bbind = (=<<)

I'm -1 on the *name* `bind`, because as others have mentioned, I feel bind has the same type as (>>=).

That said, I'm +1 on the *idea* - if we can find a better name. `joinMap` doesn't seem too bad, as was recently suggested, but I'll settle on anything other than `bind`

-- ocharles

_______________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_________________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org http://www.haskell.org/__mailman/listinfo/libraries http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Andreas Abel <>< Du bist der geliebte Mensch.

Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden

andreas.abel@gu.se http://www2.tcs.ifi.lmu.de/~abel/ _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

My sentiments are very similiar here. I find myself a weak -1 on this, because "bind" has the flipped semantics to many folks, joinMap is ugly and far longer than the alternative, (=<<) already exists, it becomes a fresh way to confuse users with monadic syntax, and it takes another precious name from the namespace. The analogies for fmap and ap strike me as false equivalences, fmap came long before the applicative sugar for (<$>), the same with ap, which long predates (<*>), and which serves canonically as a default definition for it. -Edward On Thu, Dec 11, 2014 at 3:43 AM, Andreas Abel wrote:

On 10.12.2014 17:33, John Lato wrote:

...

I don't really understand why people want this. What's wrong with (=<<) ? I kind of feel like a named function should be no longer than that.

You are right, we do not need a alphabetic version of every operator. We do not have

plus = (+)

either. Why take another good name from the user, just to avoid using an operator in parentheses?

I am -1 on the whole business here.

Cheers, Andreas

...

I don't object, especially if others think it's useful (and many clearly do), but I guess it's not to my taste.

On 08:02, Wed, Dec 10, 2014 David Feuer mailto:david.feuer@gmail.com> wrote:

joinMap looks to me like the best name, because it does just what it says on the box:

join . fmap f $ m = (m >>= return . f) >>= id --Functor/Monad law = m >>= (\x -> return (f x) >>= id) --associativity = m >>= (\x -> f x) --left identity = m >>= f --eta reduction = f =<< m

Christopher Done mailto:chrisdone@gmail.com>

writes:

> Is this defined anywhere in base, and if not could it be placed in > Control.Monad? I often find myself writing: > > fmap (mu bar) > (foo zot) > > Then I decide to change the type of x, so instead I want to just > write: > > bind (mu bar) > (foo zot) > > Which is just like fmap but the function can run in the > monad. Similar to traverse: > > (Traversable t, Applicative f) => (a -> f b) -> t a -> f (t b) > > As someone who isn’t a fan of operators, I generally am appreciative > of alternative regular plain English word versions of functions, which > I find easier to type, read and edit. Currently without defining such > a handy name, I have to transform the code to this: > > mu bar =<<foo zot > > The name for this function is a no-brainer: > > bind :: Monad m => (a -> m b) -> m a -> m bbind = (=<<)

I'm -1 on the *name* `bind`, because as others have mentioned, I feel bind has the same type as (>>=).

That said, I'm +1 on the *idea* - if we can find a better name. `joinMap` doesn't seem too bad, as was recently suggested, but I'll settle on anything other than `bind`

-- ocharles

_______________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_________________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org http://www.haskell.org/__mailman/listinfo/libraries http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Andreas Abel <>< Du bist der geliebte Mensch.

Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden

andreas.abel@gu.se http://www2.tcs.ifi.lmu.de/~abel/ _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Many people seem to be suggesting that this isn't a useful function to have, but I just found myself wanting it for a pattern that I write a lot. The code in question is: traverse (\s -> case s of Sector{..} -> liftIO (do sectorDrawWalls sectorDrawFloor sectorDrawCeiling)) =<< view sectors That is, I want to traverse some sort of structure, and the structure that I want to traverse itself comes from performing a monadic action. Imo, this would be more readable as bind (traverse (\s -> case s of Sector{..} -> liftIO (do sectorDrawWalls sectorDrawFloor sectorDrawCeiling))) (view sectors) Whatever we call it, I do feel it has use -- `traverse f =<< m` comes up a lot, but with a complex f, using =<< or >>= leads to less readability. Maybe I spend too much time with Chris. ;) -- ocharles

On Thu, 11 Dec 2014, Felipe Lessa wrote:

The infix vs prefix discussion looks like a red herring. This proposal is only about using the letters `bind` instead of the symbols `(=<<)`. Which, besides "not being letters", I can only think of "it has 5 chars instead of 4, messing with my indentation" as disadvantages.

Thus it is generally a good idea to indent with a fixed size, instead of indenting according to function names.

I like this argument order better, because it shows how (a -> m b) gets lifted into (m a -> m b). If we only get one word, and we have to choose between naming (>>=) and (=<<), I'd choose the latter for this reason. I don't care what the name is, but having an alphabetic name for most operators would be nice. Haskell's custom operators are a turn-off for several people I know. I don't think Haskell the language should push operators onto people that don't want to use them. Nor should the burden be on them to create an alias. ----- If I could go back and redesign Haskell, I'd make it so that operators could only be defined as synonyms of alphabetically-named functions. infixl 6 (+) = plus -- Dan Burton On Thu, Dec 11, 2014 at 5:37 AM, Felipe Lessa wrote:

On 11-12-2014 10:38, Henning Thielemann wrote:

...

Thus it is generally a good idea to indent with a fixed size, instead of indenting according to function names.

I agree and that's what I do. However, Chris and Oliver indented their examples by 5 spaces, which is pretty odd (pun intended), so I imagine they prefer otherwise and I've listed that as a possible disadvantage.

Cheers, :)

-- Felipe.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Well, in this case I'd use the actual bind (>>=) and write view sectors >>= do traverse $ \ s -> case s of Sector{...} -> liftIO $ do sectorDrawWalls ... more code ... ... maybe more cases ... Killed the long-ranging parentheses! Haskell rules! ;-) Cheers, Andreas On 11.12.2014 11:59, Oliver Charles wrote:

Many people seem to be suggesting that this isn't a useful function to have, but I just found myself wanting it for a pattern that I write a lot. The code in question is:

traverse (\s -> case s of Sector{..} -> liftIO (do sectorDrawWalls sectorDrawFloor sectorDrawCeiling)) =<< view sectors

That is, I want to traverse some sort of structure, and the structure that I want to traverse itself comes from performing a monadic action. Imo, this would be more readable as

bind (traverse (\s -> case s of Sector{..} -> liftIO (do sectorDrawWalls sectorDrawFloor sectorDrawCeiling))) (view sectors)

Whatever we call it, I do feel it has use -- `traverse f =<< m` comes up a lot, but with a complex f, using =<< or >>= leads to less readability. Maybe I spend too much time with Chris. ;)

-- ocharles

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel@gu.se http://www2.tcs.ifi.lmu.de/~abel/

For good or ill, concatMap has already been stolen by Data.Foldable, so that's not an easy choice. On Wed, Dec 10, 2014 at 4:48 PM, Joachim Breitner wrote:

Hi,

Am Dienstag, den 09.12.2014, 22:44 +0100 schrieb Christopher Done:

...

The name for this function is a no-brainer:

bind :: Monad m => (a -> m b) -> m a -> m b bind = (=<<)

Such a function already exists, unfortunately with a slightly too specialized type. So in the spirit of recent changes to Data.List, let’s just generalize

concatMap :: (a -> [b]) -> [a] -> [b]

to

concatMap :: Monad m => (a -> m b) -> m a -> m b

and use that existing name.

/me ducks and runs.

Greetings, Joachim

PS, jokes aside: I’m not convinced that the need for this is sufficiently strong, so this proposal, although nice and sensible, currently does not pass my rather vague threshold for change. Especially as (=<<) is (syntactically, grammatically) equivalent to a named function. So count me as -1 for now, unless better arguments arise.

-- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries