type (++) = (<>)

Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

type (++) = (<>)

varosi
Hello!

What do you think of making (++) the same as (<>) so we could use ++ as concatenation of any monoid, not just lists in Haskell 2020?
This will be more intuitive for beginners, too. 

Best regards,
Vassil Keremidchiev

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: type (++) = (<>)

Oliver Charles-3
Do you really mean at the type level?

On 3 Jul 2017 12:11 pm, "Vassil Ognyanov Keremidchiev" <[hidden email]> wrote:
Hello!

What do you think of making (++) the same as (<>) so we could use ++ as concatenation of any monoid, not just lists in Haskell 2020?
This will be more intuitive for beginners, too. 

Best regards,
Vassil Keremidchiev

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime


_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: type (++) = (<>)

Erik de Castro Lopo-34
In reply to this post by varosi
Vassil Ognyanov Keremidchiev wrote:

> What do you think of making (++) the same as (<>) so we could use ++ as
> concatenation of any monoid, not just lists in Haskell 2020?
> This will be more intuitive for beginners, too.

Two symbolic operators that are synonymous seems a bit of a waste. I would
much rather see (++) be deprecated in favour of (<>). At work we have a
custom prelude which already does this.

Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: type (++) = (<>)

Edward Kmett-2
Note: I realize nobody is directly saying that we should use (++) instead of (<>) in this conversation just yet, but I want to clear a few things up.

One of the early options when the operator (<>) was coined was to try to say we should just generalize the type of (++) instead to make it mappend. (Note: it originally was mplus, in a Haskell version long long ago, so it keeps getting repurposed!) Unfortunately, this plan ran afoul of the fact that the primary libraries using the (<>) notation at the time (pretty printing libraries) also mixed it heavily with (++), exploiting the different fixities involved. (Finding a decent fixity for (<>) was a huge chunk of the conversation at the time.)

There is a deliberate fixity difference between (++) and (<>), a good chunk of code out there mixes them that deals with pretty printing that would break pretty horribly if we just outright removed (++), and trying to do a visual search and replace for (++) with (<>) in light of them having different fixities is a very error prone process, so we aren't currently planning on deprecating the existing (++) operator any time soon. At least, nobody has put a proposal to the core libraries committee to that end.

Since the call was made to make (<>) become the new operator, we ultimately decided to leave (++) untouched, even though it could be generalized to match (<>), for much the same reason that map still exists, despite there being a more general fmap: Ultimately, there isn't a reasonable migration plan to make (++) or map become the way you define the instance involved, and at least this way the name duplication can be leveraged by the folks who want a less polymorphic combinator.

Would the world be a little tidier without map or (++) hanging about? Sure. But the hate mail levels in my inbox would skyrocket commensurately. ;)

-Edward

On Mon, Jul 3, 2017 at 5:01 PM, Erik de Castro Lopo <[hidden email]> wrote:
Vassil Ognyanov Keremidchiev wrote:

> What do you think of making (++) the same as (<>) so we could use ++ as
> concatenation of any monoid, not just lists in Haskell 2020?
> This will be more intuitive for beginners, too.

Two symbolic operators that are synonymous seems a bit of a waste. I would
much rather see (++) be deprecated in favour of (<>). At work we have a
custom prelude which already does this.

Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime


_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: type (++) = (<>)

varosi
"plus" symbol is natural denoting joining two pieces in almost all languages. That is why I would like not to get rid of it, but to be a bit more general. So in new code that will use the new prelude to be able to use it on broader range of containers (monoids/semigroups).

I really mean:
(++) :: Semigroup s => s -> s -> s

About the fixity, it could retain it's original fixity.

2017-07-04 3:24 GMT+03:00 Edward Kmett <[hidden email]>:
Note: I realize nobody is directly saying that we should use (++) instead of (<>) in this conversation just yet, but I want to clear a few things up.

One of the early options when the operator (<>) was coined was to try to say we should just generalize the type of (++) instead to make it mappend. (Note: it originally was mplus, in a Haskell version long long ago, so it keeps getting repurposed!) Unfortunately, this plan ran afoul of the fact that the primary libraries using the (<>) notation at the time (pretty printing libraries) also mixed it heavily with (++), exploiting the different fixities involved. (Finding a decent fixity for (<>) was a huge chunk of the conversation at the time.)

There is a deliberate fixity difference between (++) and (<>), a good chunk of code out there mixes them that deals with pretty printing that would break pretty horribly if we just outright removed (++), and trying to do a visual search and replace for (++) with (<>) in light of them having different fixities is a very error prone process, so we aren't currently planning on deprecating the existing (++) operator any time soon. At least, nobody has put a proposal to the core libraries committee to that end.

Since the call was made to make (<>) become the new operator, we ultimately decided to leave (++) untouched, even though it could be generalized to match (<>), for much the same reason that map still exists, despite there being a more general fmap: Ultimately, there isn't a reasonable migration plan to make (++) or map become the way you define the instance involved, and at least this way the name duplication can be leveraged by the folks who want a less polymorphic combinator.

Would the world be a little tidier without map or (++) hanging about? Sure. But the hate mail levels in my inbox would skyrocket commensurately. ;)

-Edward

On Mon, Jul 3, 2017 at 5:01 PM, Erik de Castro Lopo <[hidden email]> wrote:
Vassil Ognyanov Keremidchiev wrote:

> What do you think of making (++) the same as (<>) so we could use ++ as
> concatenation of any monoid, not just lists in Haskell 2020?
> This will be more intuitive for beginners, too.

Two symbolic operators that are synonymous seems a bit of a waste. I would
much rather see (++) be deprecated in favour of (<>). At work we have a
custom prelude which already does this.

Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime


_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime



_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: type (++) = (<>)

Cale Gibbard
On the other hand, it's unusual, at least in my mind, for "plus" to be used as notation for an operation which is noncommutative. (++) is something else of course...

While I can see moving in that direction being reasonable the migration path is a political nightmare as Edward points out.

I'm *reasonably* happy with the status quo, apart from the fact that I need to be careful a little too often whether (<>) refers to the Semigroup or Monoid operation at the moment. Moving Semigroup into base and getting those two unified would be nice. But this is really all more of a libraries issue than a language issue.

I'd actually be happy to move almost all discussion of libraries out of the Report proper, aside from what's minimally required in order to talk about the meaning of language constructs (e.g. you need Bool to talk about if-expressions, and Monad in order to discuss do-expressions, and various bits and pieces like Storable in order to discuss FFI).

To whatever extent it can, The Report should tell us all the stuff about the meaning of code that reading the libraries can't tell us.

On Tue, 4 Jul 2017 at 03:33 Vassil Ognyanov Keremidchiev <[hidden email]> wrote:
"plus" symbol is natural denoting joining two pieces in almost all languages. That is why I would like not to get rid of it, but to be a bit more general. So in new code that will use the new prelude to be able to use it on broader range of containers (monoids/semigroups).

I really mean:
(++) :: Semigroup s => s -> s -> s

About the fixity, it could retain it's original fixity.

2017-07-04 3:24 GMT+03:00 Edward Kmett <[hidden email]>:
Note: I realize nobody is directly saying that we should use (++) instead of (<>) in this conversation just yet, but I want to clear a few things up.

One of the early options when the operator (<>) was coined was to try to say we should just generalize the type of (++) instead to make it mappend. (Note: it originally was mplus, in a Haskell version long long ago, so it keeps getting repurposed!) Unfortunately, this plan ran afoul of the fact that the primary libraries using the (<>) notation at the time (pretty printing libraries) also mixed it heavily with (++), exploiting the different fixities involved. (Finding a decent fixity for (<>) was a huge chunk of the conversation at the time.)

There is a deliberate fixity difference between (++) and (<>), a good chunk of code out there mixes them that deals with pretty printing that would break pretty horribly if we just outright removed (++), and trying to do a visual search and replace for (++) with (<>) in light of them having different fixities is a very error prone process, so we aren't currently planning on deprecating the existing (++) operator any time soon. At least, nobody has put a proposal to the core libraries committee to that end.

Since the call was made to make (<>) become the new operator, we ultimately decided to leave (++) untouched, even though it could be generalized to match (<>), for much the same reason that map still exists, despite there being a more general fmap: Ultimately, there isn't a reasonable migration plan to make (++) or map become the way you define the instance involved, and at least this way the name duplication can be leveraged by the folks who want a less polymorphic combinator.

Would the world be a little tidier without map or (++) hanging about? Sure. But the hate mail levels in my inbox would skyrocket commensurately. ;)

-Edward

On Mon, Jul 3, 2017 at 5:01 PM, Erik de Castro Lopo <[hidden email]> wrote:
Vassil Ognyanov Keremidchiev wrote:

> What do you think of making (++) the same as (<>) so we could use ++ as
> concatenation of any monoid, not just lists in Haskell 2020?
> This will be more intuitive for beginners, too.

Two symbolic operators that are synonymous seems a bit of a waste. I would
much rather see (++) be deprecated in favour of (<>). At work we have a
custom prelude which already does this.

Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime


_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime


_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: type (++) = (<>)

Edward Kmett-2
On Tue, Jul 4, 2017 at 3:53 AM, Cale Gibbard <[hidden email]> wrote:
I'm *reasonably* happy with the status quo, apart from the fact that I need to be careful a little too often whether (<>) refers to the Semigroup or Monoid operation at the moment. Moving Semigroup into base and getting those two unified would be nice. 

This is already happening. In 8.4 or so this issue should finally finish resolving itself. Semigroup has already moved into base, but it is taking some time to become a superclass of Monoid.

-Edward

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: type (++) = (<>)

Edward Kmett-2
In reply to this post by varosi
Yes, I attempted to address why this was left unmolested in my last couple of paragraphs.

For comparison, we have not generalized map to have the same signature as fmap because we do not have to. fmap already exists,
having the less general signature directly indicates why it isn't possible for you to use

instance Functor Foo where
  map = ...

and a large portion of the community would like it to remain ungeneralized (often for teaching purposes). 

Given that we already have a polymorphic combinator in Prelude there is no need to make their teaching tool more awkward to teach with. As it is, teachers already have to get into typeclasses before they can talk about foldr, and this already causes a fair bit of consternation.

If we had everything to over again and no installed base? I'd probably say map should have been the member of Functor, like it is in most other languages that have anything even remotely resembling type classes at this point. The pain of transition doesn't warrant it, however.

Similarly, (<>) is winding up in Prelude as part of the Semigroup/Monoid proposal. (++) was explicitly un-generalized in Haskell 98 for teaching and error purposes, and we have (<>) present and moving into Prelude, so there isn't a real reason to go and generalize the second name and there is at least a weak justification for leaving the status quo in place.

Having two operators for the same thing means another side-condition to learn, another quirk to learn, etc. You still need to memorize which one you are allowed to define in Semigroup. The folks who write that same fiddly kind of pretty printer code do derive some benefit from keeping those operators separate. 

Finally, The status quo at least lets us dream the dream that we could remove (++) entirely from the language some day. (Even if we're unlikely to act on this impulse due to the fixity concerns raised above.)

-Edward

On Tue, Jul 4, 2017 at 3:31 AM, Vassil Ognyanov Keremidchiev <[hidden email]> wrote:
"plus" symbol is natural denoting joining two pieces in almost all languages. That is why I would like not to get rid of it, but to be a bit more general. So in new code that will use the new prelude to be able to use it on broader range of containers (monoids/semigroups).

I really mean:
(++) :: Semigroup s => s -> s -> s

About the fixity, it could retain it's original fixity.

2017-07-04 3:24 GMT+03:00 Edward Kmett <[hidden email]>:
Note: I realize nobody is directly saying that we should use (++) instead of (<>) in this conversation just yet, but I want to clear a few things up.

One of the early options when the operator (<>) was coined was to try to say we should just generalize the type of (++) instead to make it mappend. (Note: it originally was mplus, in a Haskell version long long ago, so it keeps getting repurposed!) Unfortunately, this plan ran afoul of the fact that the primary libraries using the (<>) notation at the time (pretty printing libraries) also mixed it heavily with (++), exploiting the different fixities involved. (Finding a decent fixity for (<>) was a huge chunk of the conversation at the time.)

There is a deliberate fixity difference between (++) and (<>), a good chunk of code out there mixes them that deals with pretty printing that would break pretty horribly if we just outright removed (++), and trying to do a visual search and replace for (++) with (<>) in light of them having different fixities is a very error prone process, so we aren't currently planning on deprecating the existing (++) operator any time soon. At least, nobody has put a proposal to the core libraries committee to that end.

Since the call was made to make (<>) become the new operator, we ultimately decided to leave (++) untouched, even though it could be generalized to match (<>), for much the same reason that map still exists, despite there being a more general fmap: Ultimately, there isn't a reasonable migration plan to make (++) or map become the way you define the instance involved, and at least this way the name duplication can be leveraged by the folks who want a less polymorphic combinator.

Would the world be a little tidier without map or (++) hanging about? Sure. But the hate mail levels in my inbox would skyrocket commensurately. ;)

-Edward

On Mon, Jul 3, 2017 at 5:01 PM, Erik de Castro Lopo <[hidden email]> wrote:
Vassil Ognyanov Keremidchiev wrote:

> What do you think of making (++) the same as (<>) so we could use ++ as
> concatenation of any monoid, not just lists in Haskell 2020?
> This will be more intuitive for beginners, too.

Two symbolic operators that are synonymous seems a bit of a waste. I would
much rather see (++) be deprecated in favour of (<>). At work we have a
custom prelude which already does this.

Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime


_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime




_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: type (++) = (<>)

varosi
I understand. Thank you!

2017-07-04 15:38 GMT+03:00 Edward Kmett <[hidden email]>:
Yes, I attempted to address why this was left unmolested in my last couple of paragraphs.

For comparison, we have not generalized map to have the same signature as fmap because we do not have to. fmap already exists,
having the less general signature directly indicates why it isn't possible for you to use

instance Functor Foo where
  map = ...

and a large portion of the community would like it to remain ungeneralized (often for teaching purposes). 

Given that we already have a polymorphic combinator in Prelude there is no need to make their teaching tool more awkward to teach with. As it is, teachers already have to get into typeclasses before they can talk about foldr, and this already causes a fair bit of consternation.

If we had everything to over again and no installed base? I'd probably say map should have been the member of Functor, like it is in most other languages that have anything even remotely resembling type classes at this point. The pain of transition doesn't warrant it, however.

Similarly, (<>) is winding up in Prelude as part of the Semigroup/Monoid proposal. (++) was explicitly un-generalized in Haskell 98 for teaching and error purposes, and we have (<>) present and moving into Prelude, so there isn't a real reason to go and generalize the second name and there is at least a weak justification for leaving the status quo in place.

Having two operators for the same thing means another side-condition to learn, another quirk to learn, etc. You still need to memorize which one you are allowed to define in Semigroup. The folks who write that same fiddly kind of pretty printer code do derive some benefit from keeping those operators separate. 

Finally, The status quo at least lets us dream the dream that we could remove (++) entirely from the language some day. (Even if we're unlikely to act on this impulse due to the fixity concerns raised above.)

-Edward

On Tue, Jul 4, 2017 at 3:31 AM, Vassil Ognyanov Keremidchiev <[hidden email]> wrote:
"plus" symbol is natural denoting joining two pieces in almost all languages. That is why I would like not to get rid of it, but to be a bit more general. So in new code that will use the new prelude to be able to use it on broader range of containers (monoids/semigroups).

I really mean:
(++) :: Semigroup s => s -> s -> s

About the fixity, it could retain it's original fixity.

2017-07-04 3:24 GMT+03:00 Edward Kmett <[hidden email]>:
Note: I realize nobody is directly saying that we should use (++) instead of (<>) in this conversation just yet, but I want to clear a few things up.

One of the early options when the operator (<>) was coined was to try to say we should just generalize the type of (++) instead to make it mappend. (Note: it originally was mplus, in a Haskell version long long ago, so it keeps getting repurposed!) Unfortunately, this plan ran afoul of the fact that the primary libraries using the (<>) notation at the time (pretty printing libraries) also mixed it heavily with (++), exploiting the different fixities involved. (Finding a decent fixity for (<>) was a huge chunk of the conversation at the time.)

There is a deliberate fixity difference between (++) and (<>), a good chunk of code out there mixes them that deals with pretty printing that would break pretty horribly if we just outright removed (++), and trying to do a visual search and replace for (++) with (<>) in light of them having different fixities is a very error prone process, so we aren't currently planning on deprecating the existing (++) operator any time soon. At least, nobody has put a proposal to the core libraries committee to that end.

Since the call was made to make (<>) become the new operator, we ultimately decided to leave (++) untouched, even though it could be generalized to match (<>), for much the same reason that map still exists, despite there being a more general fmap: Ultimately, there isn't a reasonable migration plan to make (++) or map become the way you define the instance involved, and at least this way the name duplication can be leveraged by the folks who want a less polymorphic combinator.

Would the world be a little tidier without map or (++) hanging about? Sure. But the hate mail levels in my inbox would skyrocket commensurately. ;)

-Edward

On Mon, Jul 3, 2017 at 5:01 PM, Erik de Castro Lopo <[hidden email]> wrote:
Vassil Ognyanov Keremidchiev wrote:

> What do you think of making (++) the same as (<>) so we could use ++ as
> concatenation of any monoid, not just lists in Haskell 2020?
> This will be more intuitive for beginners, too.

Two symbolic operators that are synonymous seems a bit of a waste. I would
much rather see (++) be deprecated in favour of (<>). At work we have a
custom prelude which already does this.

Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime


_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime





_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Loading...