Monoid wants a (++) equivalent

[Martijn van Steenbergen-2]

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.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Thomas Schilling-2]

2009/7/1 Martijn van Steenbergen <martijn@...>:
> 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@...
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@...
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

--
Push the envelope.  Watch it bend.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Thomas Schilling-2]

2009/7/1 Ross Paterson <ross@...>:
>>> 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.

Yep, it's definitely a diamond.
--
Push the envelope.  Watch it bend.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Thomas Schilling-2]

2009/7/1 David Leimbach <leimy2k@...>
> 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.

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...

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

--
Push the envelope.  Watch it bend.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Martijn van Steenbergen-2]

Thomas Schilling wrote:
> Haddock should allow documentation on instance
> declarations...

+1!

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

[Raynor Vliegendhart]

On Tue, Jun 30, 2009 at 6:45 PM, Bryan O'Sullivan<bos@...> 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 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

Another disadvantage of this approach is that we cannot have a default
monoid instance for lists (kind mismatch).
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Geoffrey Marchant]

Obviously `mappend` is good enough as it is.

Choosing (+>) or (<>) are just for prettifying code.

Generalizing (++) not only makes the code prettier, but also brings Monoid into the Prelude.

You can either Do It Right(tm), or be conservative and try to maintain backwards compatibility as much as possible.

I suspect most people in the community understand the trade-offs here, and would agree on the proper solution. If that means rewriting the standard, then so be it.

On Wed, Jul 1, 2009 at 12:26 PM, Ross Paterson <ross@...> 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.

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

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

[David Menendez-2]

In Wed, Jul 1, 2009 at 3:38 PM, Thomas Schilling<nominolo@...> wrote:
> 2009/7/1 David Leimbach <leimy2k@...>
>> 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 <dave@...>
<http://www.eyrie.org/~zednenem/>
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Jules Bean]

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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Heinrich Apfelmus]

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

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

[Alex Dunlap]

On Wed, Jul 1, 2009 at 11:26 AM, Ross Paterson<ross@...> 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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Alex Dunlap]

On Wed, Jul 1, 2009 at 10:11 PM, David Menendez<dave@...> wrote:

> In Wed, Jul 1, 2009 at 3:38 PM, Thomas Schilling<nominolo@...> wrote:
>> 2009/7/1 David Leimbach <leimy2k@...>
>>> 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 <dave@...>
> <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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Maciej Piechotka]

Ketil Malde <ketil <at> malde.org> writes:

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

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.

Regards

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

[Ross Paterson]

On Thu, Jul 02, 2009 at 12:46:37PM +0100, Jules Bean wrote:
> 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?

The Prelude is in the base package.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Johan Tibell-2]

On Thu, Jul 2, 2009 at 6:45 PM, Maciej Piechotka <uzytkownik2@...> 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
 

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

[edwardk]

 Wed, Jul 1, 2009 at 4:17 PM, Raynor Vliegendhart <shinnonoir@...> 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-Categorical.html

 

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).

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

[Richard O'Keefe]

It is claimed that making ++ become another name for the
Monoid mappend operation "will break some Haskell 98 code"
such as

        append = (++)

That example can easily be fixed by adding a type signature, no?

        append :: [a] -> [a] -> [a]
        append = (++)

In ghci, at any rate, using mappend instead of (++),
the first is rejected, but the sceond works perfectly.

The nice thing about this is that the code _with_ the type
signature is perfectly legal Haskell 98, so the fix leaves
you with something that works with either reading of (++).

Do we have any other uses of ++ that would be hard to fix
by adding a type signature?


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

[porges-2]

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`. ;)
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Jason Dusek]

2009/07/03 George Pollard <porges@...>:
> 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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Alex Dunlap]

On Fri, Jul 3, 2009 at 10:17 PM, Jason Dusek<jason.dusek@...> wrote:

> 2009/07/03 George Pollard <porges@...>:
>> 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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe