Monoid wants a (++) equivalent

[George Pollard]

2009/7/4 Jason Dusek <jason.dusek@...>:
> 2009/07/03 George Pollard <porges@...>:
>> 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`.

This is getting a little off topic, but I don't believe it has a name.
In category theory the name of the functor is used as an operation on
the function, so that given the functor "F", instead of writing `fmap
f` you'd write `F(f)`. I think this is one area where Haskell wins
notationally :)
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Brandon S. Allbery KF8NH]

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@...
system administrator [openafs,heimdal,too many hats] allbery@...
electrical and computer engineering, carnegie mellon university    KF8NH




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

[Henning Thielemann]

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

[Henning Thielemann]

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@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[edwardk]

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@...> 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@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

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

[Mattias Bengtsson]

On Sun, 2009-07-05 at 22:30 +0200, Henning Thielemann wrote:
>
> (?) 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.
Eg.
foldr _ z []     =  z
foldr (?) z (x:xs) =  x ? foldr (?) z xs

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

[Ketil Malde-5]

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