Am Dienstag 30 Juni 2009 20:56:10 schrieb David Leimbach:

On Tue, Jun 30, 2009 at 11:54 AM, Brent Yorgey wrote:

...

On Tue, Jun 30, 2009 at 09:45:45AM -0700, Bryan O'Sullivan wrote:

...

I've thought for a while that it would be very nice indeed if the Monoid class had a more concise operator for infix appending than "a `mappend`

b".

...

I wonder if other people are of a similar opinion, and if so, whether

this

...

is worth submitting a libraries@ proposal over.

+1.

IIRC Jules Bean has proposed using (+>) for this purpose, which I like. It has the advantages of (a) not clashing with any other (common) operators, (b) making more obvious the fact that mappend is not necessarily commutative, and (c) providing the obvious (<+) for 'flip mappend' which is sometimes useful.

I actually think this proposal is pretty excellent.

I actually think your assessment of the proposal is correct.

On Tue, Jun 30, 2009 at 1:33 PM, Thomas Davie wrote:

I excellently think your proposal is a correct assessment.

Well then, here's the library enhancement ticket: http://hackage.haskell.org/trac/ghc/ticket/3339

On Tue, Jun 30, 2009 at 02:54:38PM -0400, Brent Yorgey wrote:

On Tue, Jun 30, 2009 at 09:45:45AM -0700, Bryan O'Sullivan wrote:

...

I've thought for a while that it would be very nice indeed if the Monoid class had a more concise operator for infix appending than "a `mappend` b". I wonder if other people are of a similar opinion, and if so, whether this is worth submitting a libraries@ proposal over.

+1.

IIRC Jules Bean has proposed using (+>) for this purpose, which I like. It has the advantages of (a) not clashing with any other (common) operators, (b) making more obvious the fact that mappend is not necessarily commutative, and (c) providing the obvious (<+) for 'flip mappend' which is sometimes useful.

(+>) seems to imply to me that the operator is non-associative. Something like (<>) or (<+>) would be better. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/

On Tue, Jun 30, 2009 at 3:50 PM, Dougal Stanton wrote:

...

(+>) seems to imply to me that the operator is non-associative. Something like (<>) or (<+>) would be better.

It's too similar to the applicative (*>), and implies all sorts of things like different types of the two arguments and so on.

If you have comments like the above, please add them to the Trac ticket. Speaking for myself, I'll be happiest to give weight to comments that suggest alternative operators. Thanks, Bryan.

On Tue, Jun 30, 2009 at 3:56 PM, Ross Paterson wrote:

On Tue, Jun 30, 2009 at 03:39:39PM -0700, John Meacham wrote:

...

(+>) seems to imply to me that the operator is non-associative.

It does seem to imply some asymmetry between the arguments.

Well, the canonical instance of Monoid is to mappend over lists, where it doesn't commute, so I think that the pointiness of the operator makes a reasonable kind of sense.

On Tue, Jun 30, 2009 at 08:02:48PM -0400, Daniel Peebles wrote:

But we don't want to imply it's commutative either. Having something "bidirectional" like <> or <+> feels more commutative than associative to me.

Not really, think of '++', which doesn't commute but is visually symmetric, or Data.Sequence.<>, or the common use of <> to mean concatination in pretty printers. I think there is a fair amount of precedence for using '<>' actually. As it appears when it is used, it is also the natural mappend operator for the Monoid instance. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/

On Wed, Jul 01, 2009 at 12:00:50AM -0400, ajb@spamcop.net wrote:

G'day all.

On Tue, Jun 30, 2009 at 08:02:48PM -0400, Daniel Peebles wrote:

...

But we don't want to imply it's commutative either. Having something "bidirectional" like <> or <+> feels more commutative than associative to me.

Quoting John Meacham :

...

Not really, think of '++', which doesn't commute but is visually symmetric, or Data.Sequence.<>, or the common use of <> to mean concatination in pretty printers.

Other good examples are && and ||.

..wha? But those ARE commutative. Unless you mean with respect to strictness? -Brent

On 1 Jul 2009, at 16:46, Edward Kmett wrote:

I'm rather fond of the (<>) suggestion, but would be happy with anything better than mappend! ;)

I find it rather ugly, it has a lot of connotations of "does not equals" from other languages. Personally I'm in favor of <+>, simply because it looks most like a circle with a plus in it. Bob

On Wed, Jul 01, 2009 at 04:53:05PM +0200, Thomas Davie wrote:

On 1 Jul 2009, at 16:46, Edward Kmett wrote:

...

I'm rather fond of the (<>) suggestion, but would be happy with anything better than mappend! ;)

I find it rather ugly, it has a lot of connotations of "does not equals" from other languages.

Forget Pascal: think of it as a diamond.

Ross Paterson wrote:

On Wed, Jul 01, 2009 at 04:53:05PM +0200, Thomas Davie wrote:

...

On 1 Jul 2009, at 16:46, Edward Kmett wrote:

...

I'm rather fond of the (<>) suggestion, but would be happy with anything better than mappend! ;) I find it rather ugly, it has a lot of connotations of "does not equals" from other languages.

Forget Pascal: think of it as a diamond.

I too like shiny diamonds, as exemplified in http://apfelmus.nfshost.com/monoid-fingertree.html Regards, apfelmus -- http://apfelmus.nfshost.com

Robert Greayer schrieb:

I'm sure there's some important historical reason... but why isn't '&' used in something more prominent than the fgl package? I understand why it's not used for bitwise AND in Data.Bits (I assume because the corresponding bitwise '|' operator isn't available), but all the other single-character operators** (in the ASCII range) are used in some core library (if not the Prelude itself). But not '&'. Why? It makes sense (to me) as a Monoid 'append'.

(?) is also undefined in Prelude.

Mattias Bengtsson writes:

...

(?) is also undefined in Prelude.

Which i think is a good thing. I think it's quite nice to use (?) as an operator in higher order functions.

Also, it clashes with the implicit parameters extension, and combining the extension with a user-defined (?) operator resulted in (?) having a whitespace-dependent meaning, IIRC. This is perhaps not so crucial anymore, in the time since I stumbled into this -fglasgow-exts has largely been replaced by more fine-grained mechanisms, and implicit parameters has become less fashionable. -k -- If I haven't seen further, it is by standing in the footprints of giants

Duncan Coutts wrote:

I agree, if we can't use ++ then <> is the next best thing. As John says it's already a monoid operator for Data.Sequence and Text.PrettyPrint.

I agree, if we can't use +> and <+ then <> is the next best thing. ;) Jules

On Wed, Jul 1, 2009 at 5:18 AM, Jules Bean wrote:

Duncan Coutts wrote:

...

I agree, if we can't use ++ then <> is the next best thing. As John says it's already a monoid operator for Data.Sequence and Text.PrettyPrint.

I agree, if we can't use +> and <+ then <> is the next best thing.

;)

Jules

I like this thinking as well. I kind of wish Haskell didn't overload operators to begin with but oh well :-) Just because the compiler can figure out what I mean because it has a great type system, I might not be able to figure out what I mean a year from now if I see ++ everywhere. In some sense, I prefer misleading function names to overly overloaded operators. Dave

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Thomas Schilling wrote:

Haddock should allow documentation on instance declarations...

+1!

On Wed, Jul 1, 2009 at 10:11 PM, David Menendez wrote:

In Wed, Jul 1, 2009 at 3:38 PM, Thomas Schilling wrote:

...

2009/7/1 David Leimbach

...

Just because the compiler can figure out what I mean because it has a great type system, I might not be able to figure out what I mean a year from now if I see ++ everywhere.

...

Yep, had the same experience.  On the one hand, using monoids lets you delay some design decisions for later and lets you reuse more library code.  On the other hand, it sometimes makes it really hard to see what the code is actually doing--especially if you use more than one monoid.

For this reason on of the first advanced features I implemented in the (yet unreleased) scion IDE library allows you to look up the instantiated type of an identifier.  Unfortunately, jumping to the definition (or documentation) of the monoid instance is a bit more difficult.  Haddock should allow documentation on instance declarations...

I disagree. The solution is to not create instances when it isn't obvious what the instance does. That's why we have Sum and Prod in Data.Monoid instead of declaring instances directly for Int.

With Monoid, I'd go further and say that you should not use mempty and mappend unless you are writing polymorphic code. If you are writing to a specific monoid instance, you should use a specific function.

-- Dave Menendez http://www.eyrie.org/~zednenem/ _______________________________________________

I tend to disagree. I think that Haskell has seen a lot of syntax bloat in the interest of monomorphism. We have List.append, Map.union, Set.union, Sequence.><, etc., all with different notation, even though these all denote the same operation: taking two of (whatever) and combining them into one. With mappend, you know exactly what the function is supposed to do: combine two things together, and it doesn't matter what datatypes you're using, because that's always what it means. Alex

On Wed, Jul 1, 2009 at 10:55 AM, Bryan O'Sullivan wrote:

On Wed, Jul 1, 2009 at 3:38 AM, Duncan Coutts

...

wrote:

...

I agree, if we can't use ++ then <> is the next best thing.

Okay, here's a tentative plan that will help to figure out the answer. I'll build a fiddled base package that rewires the Monoid class to have (++) be the binary operator, and mappend as a synonym for it. I'll import the Monoid (++) into the Prelude. I'll see how much breaks. If that much builds smoothly, I'll see how much of the rest of Hackage builds, both with and without this custom base package. I'll follow up here with the results, along with a suggestion of how acceptable I think the observed level of breakage is.

Seem reasonable?

It's more reasonable than sitting around waxing philosophical on the notation I suppose :-)

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Ross Paterson wrote:

Generalizing (++) will break some Haskell 98 code, e.g.

append = (++)

I think that's a show-stopper.

Is the monomorphism restriction the only situation in which stuff breaks? Martijn.

Ross Paterson wrote:

On Wed, Jul 01, 2009 at 10:55:39AM -0700, Bryan O'Sullivan wrote:

...

Okay, here's a tentative plan that will help to figure out the answer. I'll build a fiddled base package that rewires the Monoid class to have (++) be the binary operator, and mappend as a synonym for it. I'll import the Monoid (++) into the Prelude. I'll see how much breaks. If that much builds smoothly, I'll see how much of the rest of Hackage builds, both with and without this custom base package. I'll follow up here with the results, along with a suggestion of how acceptable I think the observed level of breakage is.

Generalizing (++) will break some Haskell 98 code, e.g.

append = (++)

I think that's a show-stopper.

I agree it's an issue; and it's the reason I didn't even suggest it myself, favouring a new symbol. I don't think it's a show stopper, in principle. In principle you can imagine a -h98 flag which you pass to compilers which choose a strictly h98-compliant prelude as opposed to a slightly generalised newer one. I'm not the person who would have to maintain that arrangement. I guess that's a call for the people who would have to do the work. There is already a haskell98 package, I think, which is the first step? Jules

On Wed, Jul 1, 2009 at 11:26 AM, Ross Paterson wrote:

On Wed, Jul 01, 2009 at 10:55:39AM -0700, Bryan O'Sullivan wrote:

...

Okay, here's a tentative plan that will help to figure out the answer. I'll build a fiddled base package that rewires the Monoid class to have (++) be the binary operator, and mappend as a synonym for it. I'll import the Monoid (++) into the Prelude. I'll see how much breaks. If that much builds smoothly, I'll see how much of the rest of Hackage builds, both with and without this custom base package. I'll follow up here with the results, along with a suggestion of how acceptable I think the observed level of breakage is.

Generalizing (++) will break some Haskell 98 code, e.g.

 append = (++)

I think that's a show-stopper. _______________________________________________

Could we use some default rules to keep H98 code working? I don't know much about defaulting, but times = (*) works fine and defaults to type Integer. Could we not do the same thing with monoids, having monoids default to type []? Alex

This discussion points to a wider issue: at some stage we should look at pulling all the nice "new" stuff into Haskell prelude. I'm looking at you, Data.Foldable,Traversable. Also, throw out `map`. ;)

On Fri, Jul 3, 2009 at 10:17 PM, Jason Dusek wrote:

2009/07/03 George Pollard :

...

This discussion points to a wider issue: at some stage we should look at pulling all the nice "new" stuff into Haskell prelude. I'm looking at you, Data.Foldable,Traversable.

Also, throw out `map`. ;)

 What is the proper name for the operation on functions of a  functor, anyway? The name `fmap` seems to driven by an analogy  with `map`.

-- Jason Dusek _______________________________________________

I think map would be the right name. IMO, what would be really nice would be to rename "fmap" to "map" (and then fmap would become a deprecated synonym for map), etc., and get rid of many of the special cases for lists in the Prelude. The only backward compatibility problem that has been brought up is monomorphism restriction stuff, though. Alex

On Jul 4, 2009, at 01:17 , Jason Dusek wrote:

What is the proper name for the operation on functions of a functor, anyway? The name `fmap` seems to driven by an analogy with `map`.

<Cale> (.) </Cale> -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

G'day all. Quoting John Meacham :

(+>) seems to imply to me that the operator is non-associative. Something like (<>) or (<+>) would be better.

I tend to agree. Moreover, and I realise this may be a losing battle, I want (++) to be the generic operator. I understand the argument. I even agreed with it at the time. In 1998, academic use of Haskell (both for research and education) was the most important imperative. Today, Haskell is officially cool, so the good names and operators should not be stolen by operations that are distinguished only by being less useful (e.g. by working on lists alone). Cheers, Andrew Bromage

On Tue, Jun 30, 2009 at 11:24 PM, Ketil Malde wrote:

You know, this might be the right time to start expanding our vocabulary beyond seven bits.  Since we're likely to keep mappend around as an alias for some time, people would have a grace period to adjust.

How about U+2295 (circle with plus inside it)?

Or, if we would like to stick to the 8-bit subset to keep those 8859-1 users happy, how about ¤ (funny circle over an x, U+00A4)

-k -- If I haven't seen further, it is by standing in the footprints of giants _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

The major disadvantage of that is that those symbols are not on my keyboard and thus are more of a pain to type, especially on the Linux console where compose key is not available... Alex

On Thu, Jul 2, 2009 at 6:45 PM, Maciej Piechotka wrote:

I can work with any symbols as long as they are easily typeable. ++ is 3 easy key press. `mappend` is 9. In both cases I don't need to look on keyboard as I know exactly where they are. However there is no way I can remember where U+00A4 is - probably it is not on all keyboards (reversing " and @ gives me a lot of problems in UK keyboards. FR keyboards was nightmare just because a few keys where at different place). In fact I'd need to open keyboard mapping and search for symbol. A lot of trouble just for single symbol.

To summarise - It doesn't matter is symbol is or isn't in ASCII or ISO 8859-1 as long as it can be produced easily.

I would like for my font to have a glyph for it as well so my code doesn't look like tofu. -- Johan

On Wed, Jul 1, 2009 at 9:34 AM, Jochem Berndsen wrote:

ajb@spamcop.net wrote:

...

I tend to agree.  Moreover, and I realise this may be a losing battle, I want (++) to be the generic operator.

I totally agree.

So do I. David.

2009/7/1 Martijn van Steenbergen :

I suggest you all add your name and vote here:

  http://doodle.com/4yrfd7qaw5man3rm

Perhaps we'll find one of the options is clearly in favor.

Doesn't doodle allow multiple choice tests? Requiring to pick only one is kind of skewing the results towards the possibly not backwards compatible (++).

Martijn.

Bryan O'Sullivan wrote:

...

I've thought for a while that it would be very nice indeed if the Monoid class had a more concise operator for infix appending than "a `mappend` b". I wonder if other people are of a similar opinion, and if so, whether this is worth submitting a libraries@ proposal over.

------------------------------------------------------------------------

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Push the envelope. Watch it bend.

Wed, Jul 1, 2009 at 4:17 PM, Raynor Vliegendhart wrote:

We could use (Control.Category..) as an operator, but this would require an additional wrapping layer if we wish to use the existing Monoid instances:

...

import Prelude hiding (id, (.)) import Control.Category import Data.Monoid

-- Category wrapper for existing Monoid instances newtype MonoidC m a b = MonoidC {unwrapMC :: m} deriving (Show)

instance Monoid m => Category (MonoidC m) where id = MonoidC mempty MonoidC m . MonoidC n = MonoidC $ m `mappend` n

Furthermore, writing Category instances for monoids require dummy type parameters:

...

-- Example instance newtype SumC m a b = SumC {getSumC :: m} deriving (Show, Eq)

instance Num a => Category (SumC a) where id = SumC (fromIntegral 0) SumC x . SumC y = SumC $ x + y

I have a monoid-as-category and category-endomorphism as monoid in: http://comonad.com/haskell/monoids/dist/doc/html/monoids/Data-Monoid-Categor... but there are issues. 1.) these completely change the typing involved 2.) the monoid as category-with-one-object is pretty scary to someone without a category theory background. 3.) This doesn't properly represent the category-with-one-object because at best the two phantom types yield you something like a category like Hask, which has been fully connected * M where M is the category of your monoid. Even if you use GADTs to cut down the phantom types to one where the head and tail of the arrow are the same object and |.| takes a category to its discrete category (discarding all non-identity arrows) you are looking at a category like |Hask| * M because of the phantom type. data CMonoid m n o where M :: Monoid m => m -> CMonoid m a a instance Monoid m => Category (CMonoid m) where id = M mempty M a . M b = M (a `mappend` b) Attempting to go any further and railroad that type to equal m fails when you go to define id. So the categorical notion of a monoid is pretty much a non-starter in Haskell. -Edward Kmett On Another disadvantage of this approach is that we cannot have a default monoid instance for lists (kind mismatch).

While I like the idea of (++) as mappend to some extent, two objections immediately come to mind: 1.) While I like the appeal to the PVP to export a version of (++) from Data.Monoid and I think this has worked out well for new modules like Control.Category, I'm not sure that with a module that has been around for so long as Data.Monoid can be so flippant about breaking any code that imports it unqualified that also happens to use a list. Lists are everywhere in Haskell, and unqualified imports do exist. 2.) There is also a pretty big caveat in that the choice of which operator should be naturally selected for (++) _is_ ambiguous. Should it be mappend or mplus? Recall that in Haskell 1.4 (++) worked on MonadPlus and it was changed in the great monomorphism revolution of '98. -Edward Kmett On Sun, Jul 5, 2009 at 4:41 PM, Henning Thielemann < lemming@henning-thielemann.de> wrote:

On Tue, 30 Jun 2009, Bryan O'Sullivan wrote:

I've thought for a while that it would be very nice indeed if the Monoid

...

class had a more concise operator for infix appending than "a `mappend` b". I wonder if other people are of a similar opinion, and if so, whether this is worth submitting a libraries@proposal over.

We have the package version policy which relies on explicit or qualified imports, such that adding a function like (++) to Data.Monoid cannot harm any package that follow that policy. Thus I vote for not introducing a new operator, in order to keep the set of infix operators to memorize small, but use (++) for the generalized (List.++) aka mappend. The user would however need to hide (++) from Prelude.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe