Simon Hengel | 9 Jul 23:24 2013
Picon

Proposal: Add IsString instance for (Maybe a) to base

Hi,
what about adding

    instance IsString a => IsString (Maybe a) where
      fromString = Just . fromString

It makes specifying optional String/Text/... values more convenient.
Here is an example that uses System.Process.shell:

Use

    shell "ls -l" { cwd = "/home/me" }

instead of

    shell "ls -l" { cwd = Just "/home/me" }

I'm not yet sure how essential it is.  But I somehow can't see any
issues with it.  So why not?

Cheers,
Simon
Ivan Lazar Miljenovic | 10 Jul 01:21 2013
Picon

Re: Proposal: Add IsString instance for (Maybe a) to base

On 10 July 2013 07:24, Simon Hengel <sol <at> typeful.net> wrote:
> Hi,
> what about adding
>
>     instance IsString a => IsString (Maybe a) where
>       fromString = Just . fromString
>
> It makes specifying optional String/Text/... values more convenient.
> Here is an example that uses System.Process.shell:
>
> Use
>
>     shell "ls -l" { cwd = "/home/me" }
>
> instead of
>
>     shell "ls -l" { cwd = Just "/home/me" }
>
> I'm not yet sure how essential it is.  But I somehow can't see any
> issues with it.  So why not?

-0.5 from me; I think it's too easy to forget that it's a Maybe value
there when refactoring, etc.

--

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic <at> gmail.com
http://IvanMiljenovic.wordpress.com
Joachim Breitner | 10 Jul 15:55 2013
Picon

Re: Proposal: Add IsString instance for (Maybe a) to base

Hi,

Am Mittwoch, den 10.07.2013, 09:21 +1000 schrieb Ivan Lazar Miljenovic:
> -0.5 from me; I think it's too easy to forget that it's a Maybe value
> there when refactoring, etc.

same here; even with OverloadedStrings Haskell should feel as strongly
typed as it is.

Greetings,
Joachim

--

-- 
Joachim “nomeata” Breitner
  mail <at> joachim-breitner.de • http://www.joachim-breitner.de/
  Jabber: nomeata <at> joachim-breitner.de  • GPG-Key: 0x4743206C
  Debian Developer: nomeata <at> debian.org
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
David Luposchainsky | 10 Jul 16:02 2013

Re: Proposal: Add IsString instance for (Maybe a) to base

On 2013-07-10 15:55, Joachim Breitner wrote:
> Hi,
> 
> Am Mittwoch, den 10.07.2013, 09:21 +1000 schrieb Ivan Lazar Miljenovic:
>> -0.5 from me; I think it's too easy to forget that it's a Maybe value
>> there when refactoring, etc.
> 
> same here; even with OverloadedStrings Haskell should feel as strongly
> typed as it is.

Agreed. Overloaded strings should be reserved for things that *are*
strings in a certain way. A "Maybe String" is not a special way of
storing a string (like for example a "Vector Char"), it's a String with
an additional value. Providing a Maybe instance goes too far in the
direction of having a general "'return' with strings" function, so I'm
-1 on this.

David
Carter Schonwald | 11 Jul 06:57 2013
Picon

Re: Proposal: Add IsString instance for (Maybe a) to base

-1 here too. 


On Wed, Jul 10, 2013 at 10:02 AM, David Luposchainsky <dluposchainsky <at> googlemail.com> wrote:
On 2013-07-10 15:55, Joachim Breitner wrote:
> Hi,
>
> Am Mittwoch, den 10.07.2013, 09:21 +1000 schrieb Ivan Lazar Miljenovic:
>> -0.5 from me; I think it's too easy to forget that it's a Maybe value
>> there when refactoring, etc.
>
> same here; even with OverloadedStrings Haskell should feel as strongly
> typed as it is.

Agreed. Overloaded strings should be reserved for things that *are*
strings in a certain way. A "Maybe String" is not a special way of
storing a string (like for example a "Vector Char"), it's a String with
an additional value. Providing a Maybe instance goes too far in the
direction of having a general "'return' with strings" function, so I'm
-1 on this.

David


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Roman Cheplyaka | 11 Jul 15:44 2013

Re: Proposal: Add IsString instance for (Maybe a) to base

* David Luposchainsky <dluposchainsky <at> googlemail.com> [2013-07-10 16:02:25+0200]
> On 2013-07-10 15:55, Joachim Breitner wrote:
> > Hi,
> > 
> > Am Mittwoch, den 10.07.2013, 09:21 +1000 schrieb Ivan Lazar Miljenovic:
> >> -0.5 from me; I think it's too easy to forget that it's a Maybe value
> >> there when refactoring, etc.
> > 
> > same here; even with OverloadedStrings Haskell should feel as strongly
> > typed as it is.
> 
> Agreed. Overloaded strings should be reserved for things that *are*
> strings in a certain way. A "Maybe String" is not a special way of
> storing a string (like for example a "Vector Char"), it's a String with
> an additional value. Providing a Maybe instance goes too far in the
> direction of having a general "'return' with strings" function, so I'm
> -1 on this.

I concur.

Roman
Sjoerd Visscher | 11 Jul 22:22 2013

Re: Proposal: Add IsString instance for (Maybe a) to base

Could this be formalised by saying that there should be a function toString such that

  fromString . toString = id

There's no such toString for "Maybe a" with fromString = Just.

Sjoerd

On Jul 10, 2013, at 4:02 PM, David Luposchainsky <dluposchainsky <at> googlemail.com> wrote:

> On 2013-07-10 15:55, Joachim Breitner wrote:
>> Hi,
>> 
>> Am Mittwoch, den 10.07.2013, 09:21 +1000 schrieb Ivan Lazar Miljenovic:
>>> -0.5 from me; I think it's too easy to forget that it's a Maybe value
>>> there when refactoring, etc.
>> 
>> same here; even with OverloadedStrings Haskell should feel as strongly
>> typed as it is.
> 
> Agreed. Overloaded strings should be reserved for things that *are*
> strings in a certain way. A "Maybe String" is not a special way of
> storing a string (like for example a "Vector Char"), it's a String with
> an additional value. Providing a Maybe instance goes too far in the
> direction of having a general "'return' with strings" function, so I'm
> -1 on this.
> 
> David
> 
> 
> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
John Lato | 12 Jul 02:19 2013
Picon

Re: Proposal: Add IsString instance for (Maybe a) to base

To play devil's advocate, why?

What does limiting IsString in this fashion gain anyone?  It doesn't complicate type inference any more than it already is.  For any applicative, there's the trivial instance

instance (IsString a, Applicative t) => IsString (t a) where
    fromString = pure . fromString

which is conceptually a very simple step and is always total.

Of course some functors admit other instances.  I think some parser libraries already provide IsString instances as a nice syntax on matching string literals.  A rule like this would invalidate those instances for no particularly good reason I can see.


On Fri, Jul 12, 2013 at 4:22 AM, Sjoerd Visscher <sjoerd <at> w3future.com> wrote:
Could this be formalised by saying that there should be a function toString such that

  fromString . toString = id

There's no such toString for "Maybe a" with fromString = Just.

Sjoerd

On Jul 10, 2013, at 4:02 PM, David Luposchainsky <dluposchainsky <at> googlemail.com> wrote:

> On 2013-07-10 15:55, Joachim Breitner wrote:
>> Hi,
>>
>> Am Mittwoch, den 10.07.2013, 09:21 +1000 schrieb Ivan Lazar Miljenovic:
>>> -0.5 from me; I think it's too easy to forget that it's a Maybe value
>>> there when refactoring, etc.
>>
>> same here; even with OverloadedStrings Haskell should feel as strongly
>> typed as it is.
>
> Agreed. Overloaded strings should be reserved for things that *are*
> strings in a certain way. A "Maybe String" is not a special way of
> storing a string (like for example a "Vector Char"), it's a String with
> an additional value. Providing a Maybe instance goes too far in the
> direction of having a general "'return' with strings" function, so I'm
> -1 on this.
>
> David
>
>
> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Carter Schonwald | 12 Jul 03:20 2013
Picon

Re: Proposal: Add IsString instance for (Maybe a) to base

ok, framed, that way, the proposal seems much more reasonable.

When framed wrt Maybe, I immediately think "nullable values", though now that I think about it more, any use of IsString there would always be  f   a =  Just a, so even then, its philosophically kosher.

I withdraw my -1, at least for the applicative version


On Thu, Jul 11, 2013 at 8:19 PM, John Lato <jwlato <at> gmail.com> wrote:
To play devil's advocate, why?

What does limiting IsString in this fashion gain anyone?  It doesn't complicate type inference any more than it already is.  For any applicative, there's the trivial instance

instance (IsString a, Applicative t) => IsString (t a) where
    fromString = pure . fromString

which is conceptually a very simple step and is always total.

Of course some functors admit other instances.  I think some parser libraries already provide IsString instances as a nice syntax on matching string literals.  A rule like this would invalidate those instances for no particularly good reason I can see.


On Fri, Jul 12, 2013 at 4:22 AM, Sjoerd Visscher <sjoerd <at> w3future.com> wrote:
Could this be formalised by saying that there should be a function toString such that

  fromString . toString = id

There's no such toString for "Maybe a" with fromString = Just.

Sjoerd

On Jul 10, 2013, at 4:02 PM, David Luposchainsky <dluposchainsky <at> googlemail.com> wrote:

> On 2013-07-10 15:55, Joachim Breitner wrote:
>> Hi,
>>
>> Am Mittwoch, den 10.07.2013, 09:21 +1000 schrieb Ivan Lazar Miljenovic:
>>> -0.5 from me; I think it's too easy to forget that it's a Maybe value
>>> there when refactoring, etc.
>>
>> same here; even with OverloadedStrings Haskell should feel as strongly
>> typed as it is.
>
> Agreed. Overloaded strings should be reserved for things that *are*
> strings in a certain way. A "Maybe String" is not a special way of
> storing a string (like for example a "Vector Char"), it's a String with
> an additional value. Providing a Maybe instance goes too far in the
> direction of having a general "'return' with strings" function, so I'm
> -1 on this.
>
> David
>
>
> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Edward A Kmett | 12 Jul 03:32 2013
Picon

Re: Proposal: Add IsString instance for (Maybe a) to base

Even if we wanted to we cannot use that as an actual instance.

It conflicts with the most important IsString instance of all: String!

Sent from my iPhone

On Jul 11, 2013, at 9:20 PM, Carter Schonwald <carter.schonwald <at> gmail.com> wrote:

ok, framed, that way, the proposal seems much more reasonable.

When framed wrt Maybe, I immediately think "nullable values", though now that I think about it more, any use of IsString there would always be  f   a =  Just a, so even then, its philosophicall y kosher.

I withdraw my -1, at least for the applicative version


On Thu, Jul 11, 2013 at 8:19 PM, John Lato <jwlato <at> gmail.com> wrote:
To play devil's advocate, why?

What does limiting IsString in this fashion gain anyone?  It doesn't complicate type inference any more than it already is.  For any applicative, there's the trivial instance

instance (IsString a, Applicative t) => IsString (t a) where
    fromString = pure . fromString

which is conceptually a very simple step and is always total.

Of course some functors admit other instances.  I think some parser libraries already provide IsString instances as a nice syntax on matching string literals.  A rule like this would invalidate those instances for no particularly good reason I can see.


On Fri, Jul 12, 2013 at 4:22 AM, Sjoerd Visscher <sjoerd <at> w3future.com> wrote:
Could this be formalised by saying that there should be a function toString such that

  fromString . toString = id

There's no such toString for "Maybe a" with fromString = Just.

Sjoerd

On Jul 10, 2013, at 4:02 PM, David Luposchainsky <dluposchainsky <at> googlemail.com> wrote:

> On 2013-07-10 15:55, Joachim Breitner wrote:
>> Hi,
>>
>> Am Mittwoch, den 10.07.2013, 09:21 +1000 schrieb Ivan Lazar Miljenovic:
>>> -0.5 from me; I think it's too easy to forget that it's a Maybe value
>>> there when refactoring, etc.
>>
>> same here; even with OverloadedStrings Haskell should feel as strongly
>> typed as it is.
>
> Agreed. Overloaded strings should be reserved for things that *are*
> strings in a certain way. A "Maybe String" is not a special way of
> storing a string (like for example a "Vector Char"), it's a String with
> an additional value. Providing a Maybe instance goes too far in the
> direction of having a general "'return' with strings" function, so I'm
> -1 on this.
>
> David
>
>
> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
John Lato | 12 Jul 03:36 2013
Picon

Re: Proposal: Add IsString instance for (Maybe a) to base

I wasn't suggesting that we actually include that instance, just using it to demonstrate the form.


On Fri, Jul 12, 2013 at 9:32 AM, Edward A Kmett <ekmett <at> gmail.com> wrote:
Even if we wanted to we cannot use that as an actual instance.

It conflicts with the most important IsString instance of all: String!

Sent from my iPhone

On Jul 11, 2013, at 9:20 PM, Carter Schonwald <carter.schonwald <at> gmail.com> wrote:

ok, framed, that way, the proposal seems much more reasonable.

When framed wrt Maybe, I immediately think "nullable values", though now that I think about it more, any use of IsString there would always be  f   a =  Just a, so even then, its philosophically kosher.

I withdraw my -1, at least for the applicative version


On Thu, Jul 11, 2013 at 8:19 PM, John Lato <jwlato <at> gmail.com> wrote:
To play devil's advocate, why?

What does limiting IsString in this fashion gain anyone?  It doesn't complicate type inference any more than it already is.  For any applicative, there's the trivial instance

instance (IsString a, Applicative t) => IsString (t a) where
    fromString = pure . fromString

which is conceptually a very simple step and is always total.

Of course some functors admit other instances.  I think some parser libraries already provide IsString instances as a nice syntax on matching string literals.  A rule like this would invalidate those instances for no particularly good reason I can see.


On Fri, Jul 12, 2013 at 4:22 AM, Sjoerd Visscher <sjoerd <at> w3future.com> wrote:
Could this be formalised by saying that there should be a function toString such that

  fromString . toString = id

There's no such toString for "Maybe a" with fromString = Just.

Sjoerd

On Jul 10, 2013, at 4:02 PM, David Luposchainsky <dluposchainsky <at> googlemail.com> wrote:

> On 2013-07-10 15:55, Joachim Breitner wrote:
>> Hi,
>>
>> Am Mittwoch, den 10.07.2013, 09:21 +1000 schrieb Ivan Lazar Miljenovic:
>>> -0.5 from me; I think it's too easy to forget that it's a Maybe value
>>> there when refactoring, etc.
>>
>> same here; even with OverloadedStrings Haskell should feel as strongly
>> typed as it is.
>
> Agreed. Overloaded strings should be reserved for things that *are*
> strings in a certain way. A "Maybe String" is not a special way of
> storing a string (like for example a "Vector Char"), it's a String with
> an additional value. Providing a Maybe instance goes too far in the
> direction of having a general "'return' with strings" function, so I'm
> -1 on this.
>
> David
>
>
> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Carter Schonwald | 12 Jul 07:08 2013
Picon

Re: Proposal: Add IsString instance for (Maybe a) to base

good point :)

I withdraw support now that you've pointed that 


On Thu, Jul 11, 2013 at 9:32 PM, Edward A Kmett <ekmett <at> gmail.com> wrote:
Even if we wanted to we cannot use that as an actual instance.

It conflicts with the most important IsString instance of all: String!

Sent from my iPhone

On Jul 11, 2013, at 9:20 PM, Carter Schonwald <carter.schonwald <at> gmail.com> wrote:

ok, framed, that way, the proposal seems much more reasonable.

When framed wrt Maybe, I immediately think "nullable values", though now that I think about it more, any use of IsString there would always be  f   a =  Just a, so even then, its philosophically kosher.

I withdraw my -1, at least for the applicative version


On Thu, Jul 11, 2013 at 8:19 PM, John Lato <jwlato <at> gmail.com> wrote:
To play devil's advocate, why?

What does limiting IsString in this fashion gain anyone?  It doesn't complicate type inference any more than it already is.  For any applicative, there's the trivial instance

instance (IsString a, Applicative t) => IsString (t a) where
    fromString = pure . fromString

which is conceptually a very simple step and is always total.

Of course some functors admit other instances.  I think some parser libraries already provide IsString instances as a nice syntax on matching string literals.  A rule like this would invalidate those instances for no particularly good reason I can see.


On Fri, Jul 12, 2013 at 4:22 AM, Sjoerd Visscher <sjoerd <at> w3future.com> wrote:
Could this be formalised by saying that there should be a function toString such that

  fromString . toString = id

There's no such toString for "Maybe a" with fromString = Just.

Sjoerd

On Jul 10, 2013, at 4:02 PM, David Luposchainsky <dluposchainsky <at> googlemail.com> wrote:

> On 2013-07-10 15:55, Joachim Breitner wrote:
>> Hi,
>>
>> Am Mittwoch, den 10.07.2013, 09:21 +1000 schrieb Ivan Lazar Miljenovic:
>>> -0.5 from me; I think it's too easy to forget that it's a Maybe value
>>> there when refactoring, etc.
>>
>> same here; even with OverloadedStrings Haskell should feel as strongly
>> typed as it is.
>
> Agreed. Overloaded strings should be reserved for things that *are*
> strings in a certain way. A "Maybe String" is not a special way of
> storing a string (like for example a "Vector Char"), it's a String with
> an additional value. Providing a Maybe instance goes too far in the
> direction of having a general "'return' with strings" function, so I'm
> -1 on this.
>
> David
>
>
> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Roman Cheplyaka | 12 Jul 08:04 2013

Re: Proposal: Add IsString instance for (Maybe a) to base

Because what IsString essentially does is it adds implicit conversions.

Implicit conversions make code harder to understand. They also lead to
all sorts of WATs. (See the famous presentation.)

We can already make Perlish things like

  instance IsString Int where fromString = length

I think we need some rules telling us what is or is not okay.

To be clear, people should be able to declare whatever instances they
think are reasonable in their code. But it's a different matter to make
this effectively part of the language.

Roman

* John Lato <jwlato <at> gmail.com> [2013-07-12 08:19:05+0800]
> To play devil's advocate, why?
> 
> What does limiting IsString in this fashion gain anyone?  It doesn't
> complicate type inference any more than it already is.  For any
> applicative, there's the trivial instance
> 
> instance (IsString a, Applicative t) => IsString (t a) where
>     fromString = pure . fromString
> 
> which is conceptually a very simple step and is always total.
> 
> Of course some functors admit other instances.  I think some parser
> libraries already provide IsString instances as a nice syntax on matching
> string literals.  A rule like this would invalidate those instances for no
> particularly good reason I can see.
> 
> 
> On Fri, Jul 12, 2013 at 4:22 AM, Sjoerd Visscher <sjoerd <at> w3future.com>wrote:
> 
> > Could this be formalised by saying that there should be a function
> > toString such that
> >
> >   fromString . toString = id
> >
> > There's no such toString for "Maybe a" with fromString = Just.
> >
> > Sjoerd
> >
> > On Jul 10, 2013, at 4:02 PM, David Luposchainsky <
> > dluposchainsky <at> googlemail.com> wrote:
> >
> > > On 2013-07-10 15:55, Joachim Breitner wrote:
> > >> Hi,
> > >>
> > >> Am Mittwoch, den 10.07.2013, 09:21 +1000 schrieb Ivan Lazar Miljenovic:
> > >>> -0.5 from me; I think it's too easy to forget that it's a Maybe value
> > >>> there when refactoring, etc.
> > >>
> > >> same here; even with OverloadedStrings Haskell should feel as strongly
> > >> typed as it is.
> > >
> > > Agreed. Overloaded strings should be reserved for things that *are*
> > > strings in a certain way. A "Maybe String" is not a special way of
> > > storing a string (like for example a "Vector Char"), it's a String with
> > > an additional value. Providing a Maybe instance goes too far in the
> > > direction of having a general "'return' with strings" function, so I'm
> > > -1 on this.
> > >
> > > David
> > >
> > >
> > > _______________________________________________
> > > Libraries mailing list
> > > Libraries <at> haskell.org
> > > http://www.haskell.org/mailman/listinfo/libraries
> >
> >
> > _______________________________________________
> > Libraries mailing list
> > Libraries <at> haskell.org
> > http://www.haskell.org/mailman/listinfo/libraries
> >

> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
Gabriel Gonzalez | 12 Jul 06:57 2013
Picon

Re: Proposal: Add IsString instance for (Maybe a) to base

> To play devil's advocate, why?
>
> What does limiting IsString in this fashion gain anyone?  It doesn't
> complicate type inference any more than it already is.  For any
> applicative, there's the trivial instance
>
> instance (IsString a, Applicative t) =>  IsString (t a) where
>      fromString = pure . fromString
>
> which is conceptually a very simple step and is always total.
>
> Of course some functors admit other instances.  I think some parser
> libraries already provide IsString instances as a nice syntax on matching
> string literals.  A rule like this would invalidate those instances for no
> particularly good reason I can see.
There is a tension between the "Do what I say" approach to library 
design and the "Do what I mean" approach where the library guesses at 
the programmer's intention and tries to succeed at all cost, sometimes 
failing silently when it guesses wrong.  The Haskell development 
philosophy seems to err on the side of avoiding mistakes, which leads me 
to favor asking the programmer to be explicit in this particular case 
and not auto-inserting `Just`s for them.

Also, scope creep for type classes like `IsString` makes it more 
difficult to reason about what their methods mean.  These more exotic 
`IsString` instances dilute the meaning and precision of the original 
type class.  When I wrote a string in a program with `OverloadedStrings` 
enabled, the meaning used to be: "This is text".  Then the meaning 
became: "This uses text internally, somewhere."  As time goes on, I 
expect the meaning will eventually become: "This is convenient", 
whatever that means.
John Lato | 12 Jul 07:56 2013
Picon

Re: Proposal: Add IsString instance for (Maybe a) to base

On Fri, Jul 12, 2013 at 12:57 PM, Gabriel Gonzalez <gabriel439 <at> gmail.com> wrote:
To play devil's advocate, why?

What does limiting IsString in this fashion gain anyone?  It doesn't
complicate type inference any more than it already is.  For any
applicative, there's the trivial instance

instance (IsString a, Applicative t) =>  IsString (t a) where
     fromString = pure . fromString

which is conceptually a very simple step and is always total.

Of course some functors admit other instances.  I think some parser
libraries already provide IsString instances as a nice syntax on matching
string literals.  A rule like this would invalidate those instances for no
particularly good reason I can see.
There is a tension between the "Do what I say" approach to library design and the "Do what I mean" approach where the library guesses at the programmer's intention and tries to succeed at all cost, sometimes failing silently when it guesses wrong.  The Haskell development philosophy seems to err on the side of avoiding mistakes, which leads me to favor asking the programmer to be explicit in this particular case and not auto-inserting `Just`s for them.

The programmer is being explicit; the type specifies the value is a Maybe.  If it weren't, the Just wouldn't be inserted.

Can you provide an example of code that compiles with this instance and does the wrong thing?  I'm afraid I don't see a conflict between DWIS/DWIM here, as I cannot envision any situation where this would "guess wrong".  I also cannot comprehend code where this instance would ever do anything other than "what I say".

I can see a case where a user may be requested to supply an additional type annotation, however that's already true.

Also, scope creep for type classes like `IsString` makes it more difficult to reason about what their methods mean.  These more exotic `IsString` instances dilute the meaning and precision of the original type class.  When I wrote a string in a program with `OverloadedStrings` enabled, the meaning used to be: "This is text".  Then the meaning became: "This uses text internally, somewhere."  As time goes on, I expect the meaning will eventually become: "This is convenient", whatever that means.

I prefer to think of the meaning as "a mapping from string literals into the instance type."  This quite closely with both the use of OverloadedStrings and the type of fromString.  It's also perfectly compatible with a more general notion of IsString as proposed.  What you consider scope creep is simply an artificial restriction of a more general instance.
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Roman Cheplyaka | 12 Jul 08:13 2013

Re: Proposal: Add IsString instance for (Maybe a) to base

* John Lato <jwlato <at> gmail.com> [2013-07-12 13:56:31+0800]
> The programmer is being explicit; the type specifies the value is a Maybe.
>  If it weren't, the Just wouldn't be inserted.

Not necessarily — take Simon's original example:

  (shell "ls -l") { cwd = "/home/me" }

If I didn't know the type of 'cwd', it would never occur to me while
reading this code that you can supply Nothing there.

Also, the fact that you can omit Just with string literals but not with
string values or values of other types creates an unnecessary
irregularity in the language.

Roman

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
John Lato | 12 Jul 08:45 2013
Picon

Re: Proposal: Add IsString instance for (Maybe a) to base

On Fri, Jul 12, 2013 at 2:13 PM, Roman Cheplyaka <roma <at> ro-che.info> wrote:
* John Lato <jwlato <at> gmail.com> [2013-07-12 13:56:31+0800]
> The programmer is being explicit; the type specifies the value is a Maybe.
>  If it weren't, the Just wouldn't be inserted.

Not necessarily — take Simon's original example:

  (shell "ls -l") { cwd = "/home/me" }

If I didn't know the type of 'cwd', it would never occur to me while
reading this code that you can supply Nothing there.

So?  If you're just reading the code, it doesn't matter.  If you want to modify the code, presumably you would want to examine CreateProcess to at least get a glimpse of the types of fields.  And if you wanted to modify the code to use the default value, I think a natural instinct would be to just do

    (shell "ls -l")

which again would do the right thing.

Also, the fact that you can omit Just with string literals but not with
string values or values of other types creates an unnecessary
irregularity in the language.

OverloadedStrings (and number literals) are already a mess for this.  Currently, we have

    (shell "ls -l") { cwd = Just "/home/me" }

If I want to replace that literal with a value and I don't know the type of 'cwd', I already need to look it up.  Otherwise I might try to do something like this:

    dirFromUser <- Text.getLine
    (shell "ls -l") { cwd = Just dirFromUser }

and get a type error because it's expecting a Maybe String, not a Maybe Text.  This happens to me very frequently, unless I remember to look up the record/function/whatever first to see what type is expected.

I don't think adding a Just is any different from this situation.  In either case, if you know the type of the thing you'll get the changes correct.  If you don't know the type you're likely to either get it wrong or have to look it up.  But as usual, the type makes it completely clear.

A decent IDE helps a lot if you don't know the types of things in your code.  Everyone should use one.

Also, one nice thing about OverloadedStrings is that this doesn't need to be baked in.  A library with a few orphan instances along these lines could easily be provided separately.
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Evan Laforge | 12 Jul 09:57 2013
Picon

Re: Proposal: Add IsString instance for (Maybe a) to base

On Fri, Jul 12, 2013 at 2:45 AM, John Lato <jwlato <at> gmail.com> wrote:
> On Fri, Jul 12, 2013 at 2:13 PM, Roman Cheplyaka <roma <at> ro-che.info> wrote:
>>
>> * John Lato <jwlato <at> gmail.com> [2013-07-12 13:56:31+0800]
>> > The programmer is being explicit; the type specifies the value is a
>> > Maybe.
>> >  If it weren't, the Just wouldn't be inserted.
>>
>> Not necessarily — take Simon's original example:
>>
>>   (shell "ls -l") { cwd = "/home/me" }
>>
>> If I didn't know the type of 'cwd', it would never occur to me while
>> reading this code that you can supply Nothing there.
>
> So?  If you're just reading the code, it doesn't matter.  If you want to

It does to me!  Concrete types help me read.  I have a lot of trouble
understanding libraries that make extensive use of typeclasses, both
reading their documentation and reading code that uses them.

> OverloadedStrings (and number literals) are already a mess for this.
> Currently, we have
>
>     (shell "ls -l") { cwd = Just "/home/me" }
>
> If I want to replace that literal with a value and I don't know the type of
> 'cwd', I already need to look it up.  Otherwise I might try to do something
> like this:
>
>     dirFromUser <- Text.getLine
>     (shell "ls -l") { cwd = Just dirFromUser }

I probably wouldn't, because I know the process package uses Strings.

In general though I agree, with overloading there's a bit of a mess,
but that's not license to expand the mess.

> A decent IDE helps a lot if you don't know the types of things in your code.
> Everyone should use one.

It sounds reasonable in theory, but I've never seen an IDE I would
call "decent".

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
John Lato | 12 Jul 11:03 2013
Picon

Re: Proposal: Add IsString instance for (Maybe a) to base

On Fri, Jul 12, 2013 at 3:57 PM, Evan Laforge <qdunkan <at> gmail.com> wrote:
On Fri, Jul 12, 2013 at 2:45 AM, John Lato <jwlato <at> gmail.com> wrote:
> On Fri, Jul 12, 2013 at 2:13 PM, Roman Cheplyaka <roma <at> ro-che.info> wrote:
>>
>> * John Lato <jwlato <at> gmail.com> [2013-07-12 13:56:31+0800]
>> > The programmer is being explicit; the type specifies the value is a
>> > Maybe.
>> >  If it weren't, the Just wouldn't be inserted.
>>
>> Not necessarily — take Simon's original example:
>>
>>   (shell "ls -l") { cwd = "/home/me" }
>>
>> If I didn't know the type of 'cwd', it would never occur to me while
>> reading this code that you can supply Nothing there.
>
> So?  If you're just reading the code, it doesn't matter.  If you want to

It does to me!  Concrete types help me read.  I have a lot of trouble
understanding libraries that make extensive use of typeclasses, both
reading their documentation and reading code that uses them.

I agree completely, but it's already typeclass-based as soon as you enable OverloadedStrings.  If you want concrete types, just don't use OverloadedStrings and you'll be good.
 

> OverloadedStrings (and number literals) are already a mess for this.
> Currently, we have
>
>     (shell "ls -l") { cwd = Just "/home/me" }
>
> If I want to replace that literal with a value and I don't know the type of
> 'cwd', I already need to look it up.  Otherwise I might try to do something
> like this:
>
>     dirFromUser <- Text.getLine
>     (shell "ls -l") { cwd = Just dirFromUser }

I probably wouldn't, because I know the process package uses Strings.

In all seriousness, I'm not that fond of the proposal myself.  I just wanted to argue the other side because nobody else was.  But so far, I've seen two main arguments against the proposal:

1.  IsString is for things that are notionally some sort of string.
2.  It makes the types more confusing.

The second seems like a weak argument to me.  First off, the proposal seems very similar to the recent generalization of Prelude.map, which had a great deal of support.  Secondly, this objection appears to posit a programmer who knows the types well enough to differentiate between String/Text/ByteString, but not well enough to differentiate String/Maybe String.  Which I suppose may be the case.  It's easier to remember "package X uses Strings" than having to remember "X.foo :: String, X.bar :: Maybe String" etc.  But I end up looking up the types of things quite frequently already, and I don't believe that this addition would have a very large impact on the number of type lookups I perform.

I find the first argument more convincing, but I'm starting to think it's nothing more than a self-imposed limitation.  Right now, most people seem to think IsString should mean "this data is notionally a string".  I think that even Maybe String/Text fits that definition.  But it seems even better to give IsString the meaning "string literals represent values of this type".  It's both closer to how OverloadedStrings interprets IsString instances and more general.  With this meaning, the slippery slope to other applicatives isn't a slope at all.

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Roman Cheplyaka | 12 Jul 12:29 2013

Re: Proposal: Add IsString instance for (Maybe a) to base

* John Lato <jwlato <at> gmail.com> [2013-07-12 17:03:03+0800]
> In all seriousness, I'm not that fond of the proposal myself.  I just
> wanted to argue the other side because nobody else was.  But so far, I've
> seen two main arguments against the proposal:
> 
> 1.  IsString is for things that are notionally some sort of string.
> 2.  It makes the types more confusing.
> 
> The second seems like a weak argument to me.  First off, the proposal seems
> very similar to the recent generalization of Prelude.map, which had a great
> deal of support.

The difference is that fromString is called implicitly.

A similar precedent is numeric literals. When I type 1, a method is
called, but most of the time I don't need to think about it because
those methods agree with my intuitive semantics of numbers.

It's easy to define a more or less proper instance

  instance (Applicative t, Num n) => Num (t n)

which would allow to overload numbers even harder, but then I'd need to
stop and think every time I see a number.

Roman
Ben Millwood | 14 Jul 02:44 2013
Picon

Re: Proposal: Add IsString instance for (Maybe a) to base

On Fri, Jul 12, 2013 at 01:29:43PM +0300, Roman Cheplyaka wrote:
>* John Lato <jwlato <at> gmail.com> [2013-07-12 17:03:03+0800]
>> In all seriousness, I'm not that fond of the proposal myself.  I just
>> wanted to argue the other side because nobody else was.  But so far, I've
>> seen two main arguments against the proposal:
>>
>> 1.  IsString is for things that are notionally some sort of string.
>> 2.  It makes the types more confusing.
>>
>> The second seems like a weak argument to me.  First off, the proposal seems
>> very similar to the recent generalization of Prelude.map, which had a great
>> deal of support.
>
>The difference is that fromString is called implicitly.
>
>A similar precedent is numeric literals. When I type 1, a method is
>called, but most of the time I don't need to think about it because
>those methods agree with my intuitive semantics of numbers.
>
>It's easy to define a more or less proper instance
>
>  instance (Applicative t, Num n) => Num (t n)
>
>which would allow to overload numbers even harder, but then I'd need to
>stop and think every time I see a number.
>
>Roman

I agree. When I see a string literal in the source code of a program, I 
want to be able to think of it as, well, a string. Not necessarily a 
String with a capital S, but a string of some sort nonetheless. A Maybe 
String is no such thing! The idea is only slightly less ridiculous than 
having a literal denote its singleton list, or singleton set, or tree 
with one leaf.

(so -1 from me)
Gabriel Gonzalez | 12 Jul 13:25 2013
Picon

Re: Proposal: Add IsString instance for (Maybe a) to base

On 07/12/2013 02:03 AM, John Lato wrote:
> In all seriousness, I'm not that fond of the proposal myself.  I just 
> wanted to argue the other side because nobody else was.

I appreciate that! :)  I, too, enjoy playing the devil's advocate.

> But so far, I've seen two main arguments against the proposal:
>
> 1.  IsString is for things that are notionally some sort of string.
> 2.  It makes the types more confusing.
>
> The second seems like a weak argument to me.  First off, the proposal 
> seems very similar to the recent generalization of Prelude.map, which 
> had a great deal of support.

There is a difference between type-classing `fmap` and type-classing 
string literals.  `fmap` has laws governing its behavior that preserve a 
certain intuition and keep the instance writer on the straight and 
narrow path.

Speaking of which, it would be an improvement if `fromString` instances 
some sort of functor laws, even if they were not totally rigorous and 
the destination category is changing on an instance-by-instance basis.  
For example, the `String`/`Text`/`ByteString` instances for `fromString` 
should obey (or *mostly* obey) these laws:

     fromString (str1 <> str2) = fromString str1 <> fromString str2 :: 
Vector Char/Text/ByteString
     fromString mempty = mempty

Whereas the parser instances you mentioned would probably satisfy the 
following laws, at least for the `attoparsec` library, if the `string` 
parser returned `()` instead of the parsed string:

     fromString (str1 <> str2) = fromString str1 >> fromString str2 :: 
Parser ()
     fromString mempty = return ()

I think the treatment of `fromString` as a functor from the String 
monoid to some other category is the closest theoretical statement of 
your intuition that an `IsString` instance should "represent" a `String`.

Notice that this treatment actually rejects the proposed `Maybe` 
instance, since:

fromString mempty /= (mempty :: (IsString a) => Maybe a)

`mempty` should evaluate to `Nothing` in that context, but the proposal 
suggests it should be `Just ""`.  You could argue that the current 
`Monoid` instance for `Maybe` is the wrong one and that `Just ""` is the 
correct identity, but then that would just confirm that the correct 
behavior is underspecified in this case and it is better to not let the 
programmer guess which behavior we meant.
John Lato | 15 Jul 02:20 2013
Picon

Re: Proposal: Add IsString instance for (Maybe a) to base

On Fri, Jul 12, 2013 at 7:25 PM, Gabriel Gonzalez <gabriel439 <at> gmail.com> wrote:
On 07/12/2013 02:03 AM, John Lato wrote:
In all seriousness, I'm not that fond of the proposal myself.  I just wanted to argue the other side because nobody else was.

I appreciate that! :)  I, too, enjoy playing the devil's advocate.


But so far, I've seen two main arguments against the proposal:

1.  IsString is for things that are notionally some sort of string.
2.  It makes the types more confusing.

The second seems like a weak argument to me.  First off, the proposal seems very similar to the recent generalization of Prelude.map, which had a great deal of support.

There is a difference between type-classing `fmap` and type-classing string literals.  `fmap` has laws governing its behavior that preserve a certain intuition and keep the instance writer on the straight and narrow path.

Speaking of which, it would be an improvement if `fromString` instances some sort of functor laws, even if they were not totally rigorous and the destination category is changing on an instance-by-instance basis.  For example, the `String`/`Text`/`ByteString` instances for `fromString` should obey (or *mostly* obey) these laws:

    fromString (str1 <> str2) = fromString str1 <> fromString str2 :: Vector Char/Text/ByteString
    fromString mempty = mempty

None of this addresses my argument.  That is, you (and most others) want to use IsString to denote things that are in some sense strings.  This proposed distribution of fromstring over mappend is a reasonable attempt to formalize what it means to be string-like.  But my point is that this may be the wrong intuition.  I don't see any reason why IsString should be restricted to just notional strings.
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Anton Nikishaev | 14 Jul 16:04 2013
Picon

Re: Proposal: Add IsString instance for (Maybe a) to base

Simon Hengel <sol <at> typeful.net> writes:

> Hi,
> what about adding
>
>     instance IsString a => IsString (Maybe a) where
>       fromString = Just . fromString
>
> It makes specifying optional String/Text/... values more convenient.
> Here is an example that uses System.Process.shell:
>
> Use
>
>     shell "ls -l" { cwd = "/home/me" }
>
> instead of
>
>     shell "ls -l" { cwd = Just "/home/me" }
>
> I'm not yet sure how essential it is.  But I somehow can't see any
> issues with it.  So why not?

-1.  It's called *IsString*.

--

-- 
lelf
Conrad Parker | 15 Jul 03:40 2013

Re: Proposal: Add IsString instance for (Maybe a) to base

On 10 July 2013 05:24, Simon Hengel <sol <at> typeful.net> wrote:
> Hi,
> what about adding
>
>     instance IsString a => IsString (Maybe a) where
>       fromString = Just . fromString
>
> It makes specifying optional String/Text/... values more convenient.
> Here is an example that uses System.Process.shell:
>
> Use
>
>     shell "ls -l" { cwd = "/home/me" }
>
> instead of
>
>     shell "ls -l" { cwd = Just "/home/me" }
>
> I'm not yet sure how essential it is.  But I somehow can't see any
> issues with it.  So why not?

+1

After reviewing the resulting discussion I agree that there's no
possible ambiguity and Simon's use-case is compelling. I think it's
great that this allows us to write obvious code without cluttering the
common use-case with Justs, while still allowing the underlying types
to be properly expressive (ie. admitting a Nothing value when that is
appropriate). This is especially important for a DSL that uses lots of
strings, like shell scripting.

I think (Maybe String) is a perfectly good string; it's just a string
type that has an extra value of Nothing -- and Nothing doesn't even
play a part in the IsString instance.

Conrad.
Edward Kmett | 15 Jul 04:43 2013
Picon

Re: Proposal: Add IsString instance for (Maybe a) to base

I was at first against this proposal by a knee jerk "but it isn't a string" response. 


But now, after considering it, I'm (mildly) in favor of this proposal just because a.) it only affects you once you've turned on OverloadedStrings which serves as a clear indication that hinky stuff might be going on, and b.) it is the only place such an instance could live that isn't an orphan and c.) it is the least prescriptive option. Very few of the users in the more prescriptivist camp are using OverloadedStrings to begin with. ;)

The proposed laws for how fromString and Monoid should relate largely ignore the existing usecases people have for tokenizing parsers and embedding string literals in ASTs -- which as I recall was a decent part of why Lennart originally put fromString forward, so I'm not sure I can concede the moral high ground to those citing the fact that we might want to put laws on the class. It might have been nice to put some laws in place about the class, but the laws that have been put forth largely ignore how this language extension gets used in practice.

-Edward

On Sun, Jul 14, 2013 at 9:40 PM, Conrad Parker <conrad <at> metadecks.org> wrote:
On 10 July 2013 05:24, Simon Hengel <sol <at> typeful.net> wrote:
> Hi,
> what about adding
>
>     instance IsString a => IsString (Maybe a) where
>       fromString = Just . fromString
>
> It makes specifying optional String/Text/... values more convenient.
> Here is an example that uses System.Process.shell:
>
> Use
>
>     shell "ls -l" { cwd = "/home/me" }
>
> instead of
>
>     shell "ls -l" { cwd = Just "/home/me" }
>
> I'm not yet sure how essential it is.  But I somehow can't see any
> issues with it.  So why not?

+1

After reviewing the resulting discussion I agree that there's no
possible ambiguity and Simon's use-case is compelling. I think it's
great that this allows us to write obvious code without cluttering the
common use-case with Justs, while still allowing the underlying types
to be properly expressive (ie. admitting a Nothing value when that is
appropriate). This is especially important for a DSL that uses lots of
strings, like shell scripting.

I think (Maybe String) is a perfectly good string; it's just a string
type that has an extra value of Nothing -- and Nothing doesn't even
play a part in the IsString instance.

Conrad.

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
MightyByte | 15 Jul 14:26 2013
Picon

Re: Proposal: Add IsString instance for (Maybe a) to base

I'll just throw out a data point related to this discussion.  In one of my previous commercial Haskell projects we ended up writing a similar Num instance for Maybe a.  I think I asked about it in #haskell back then and got pretty vocal distaste about the idea from several people who spoke up.  "Maybe is not a number!"  But we did end up using the instance in our project because it greatly simplified a section of our code.  I'm certainly not going to recommend that we also add the Num instance for Maybe.  But I think it's a useful data point that this happened in real-world production code at a company where writing Haskell code was my full-time job.

As for my personal opinion on this proposal, I'm on the fence.  I can see how it would be nice to have this kind of convenience, but the arguments on the opposing side also resonate with me as well.


On Sun, Jul 14, 2013 at 10:43 PM, Edward Kmett <ekmett <at> gmail.com> wrote:
I was at first against this proposal by a knee jerk "but it isn't a string" response. 

But now, after considering it, I'm (mildly) in favor of this proposal just because a.) it only affects you once you've turned on OverloadedStrings which serves as a clear indication that hinky stuff might be going on, and b.) it is the only place such an instance could live that isn't an orphan and c.) it is the least prescriptive option. Very few of the users in the more prescriptivist camp are using OverloadedStrings to begin with. ;)

The proposed laws for how fromString and Monoid should relate largely ignore the existing usecases people have for tokenizing parsers and embedding string literals in ASTs -- which as I recall was a decent part of why Lennart originally put fromString forward, so I'm not sure I can concede the moral high ground to those citing the fact that we might want to put laws on the class. It might have been nice to put some laws in place about the class, but the laws that have been put forth largely ignore how this language extension gets used in practice.

-Edward

On Sun, Jul 14, 2013 at 9:40 PM, Conrad Parker <conrad <at> metadecks.org> wrote:
On 10 July 2013 05:24, Simon Hengel <sol <at> typeful.net> wrote:
> Hi,
> what about adding
>
>     instance IsString a => IsString (Maybe a) where
>       fromString = Just . fromString
>
> It makes specifying optional String/Text/... values more convenient.
> Here is an example that uses System.Process.shell:
>
> Use
>
>     shell "ls -l" { cwd = "/home/me" }
>
> instead of
>
>     shell "ls -l" { cwd = Just "/home/me" }
>
> I'm not yet sure how essential it is.  But I somehow can't see any
> issues with it.  So why not?

+1

After reviewing the resulting discussion I agree that there's no
possible ambiguity and Simon's use-case is compelling. I think it's
great that this allows us to write obvious code without cluttering the
common use-case with Justs, while still allowing the underlying types
to be properly expressive (ie. admitting a Nothing value when that is
appropriate). This is especially important for a DSL that uses lots of
strings, like shell scripting.

I think (Maybe String) is a perfectly good string; it's just a string
type that has an extra value of Nothing -- and Nothing doesn't even
play a part in the IsString instance.

Conrad.

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Henning Thielemann | 15 Jul 17:24 2013
Picon

Re: Proposal: Add IsString instance for (Maybe a) to base


On Mon, 15 Jul 2013, MightyByte wrote:

> I'll just throw out a data point related to this discussion.  In one of my previous commercial Haskell
> projects we ended up writing a similar Num instance for Maybe a.  I think I asked about it in #haskell back
> then and got pretty vocal distaste about the idea from several people who spoke up.  "Maybe is not a
> number!"  But we did end up using the instance in our project because it greatly simplified a section of our
> code.

I also had this analogy in mind. Looks like syntactic heroin.

Like (IsString (Maybe String)) does not fulfill intuitive laws, (Num 
(Maybe a)) does not, too. E.g. if in your code you see 'a+b-b' you would 
like to simplify that to 'a'. With a Maybe instance this is not true in 
case 'b' is Nothing.

>  I'm certainly not going to recommend that we also add the Num instance 
> for Maybe.  But I think it's a useful data point that this happened in 
> real-world production code at a company where writing Haskell code was 
> my full-time job.

This confirms that real world code contains a lot of mess.
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Sturdy, Ian | 15 Jul 18:21 2013

RE: Proposal: Add IsString instance for (Maybe a) to base

> Like (IsString (Maybe String)) does not fulfill intuitive laws, (Num
(Maybe a)) does not, too. E.g. if in your code you see 'a+b-b' you would
like to simplify that to 'a'. With a Maybe instance this is not true in
case 'b' is Nothing.

It also violates that rule if `a :: Float` and b is NaN. Should we abolish the Num instance of Float? In any
event, I think the example contrived--the only conceivable reason I see for adding zero in such a creative
way is to introduce an evaluation dependency, in which case returning Nothing if `b == Nothing` is exactly
what I want. Consider also among unquestionably useful instances that violate simple prejudice the Num
instance for `Num a => Set a`, where `a + {1,-1} - {1,-1} == {a-2,a,a+2}`.

As for the original proposal, I am a tentative +1; the proposed standards for isString instances are
already violated (I think of Attoparsec's instance for Parser). OverloadedStrings is already somewhat
far down the road of convenience, and this would be most useful in certain places.

Ian Sturdy
________________________________________
From: Libraries [libraries-bounces <at> haskell.org] on behalf of Henning Thielemann [lemming <at> henning-thielemann.de]
Sent: Monday, July 15, 2013 11:24 AM
To: MightyByte
Cc: Haskell Libraries
Subject: Re: Proposal: Add IsString instance for (Maybe a) to base

On Mon, 15 Jul 2013, MightyByte wrote:

> I'll just throw out a data point related to this discussion.  In one of my previous commercial Haskell
> projects we ended up writing a similar Num instance for Maybe a.  I think I asked about it in #haskell back
> then and got pretty vocal distaste about the idea from several people who spoke up.  "Maybe is not a
> number!"  But we did end up using the instance in our project because it greatly simplified a section of our
> code.

I also had this analogy in mind. Looks like syntactic heroin.

Like (IsString (Maybe String)) does not fulfill intuitive laws, (Num
(Maybe a)) does not, too. E.g. if in your code you see 'a+b-b' you would
like to simplify that to 'a'. With a Maybe instance this is not true in
case 'b' is Nothing.

>  I'm certainly not going to recommend that we also add the Num instance
> for Maybe.  But I think it's a useful data point that this happened in
> real-world production code at a company where writing Haskell code was
> my full-time job.

This confirms that real world code contains a lot of mess.
Henning Thielemann | 15 Jul 18:32 2013
Picon

RE: Proposal: Add IsString instance for (Maybe a) to base


On Mon, 15 Jul 2013, Sturdy, Ian wrote:

> Consider also among unquestionably useful instances that violate simple 
> prejudice the Num instance for `Num a => Set a`, where `a + {1,-1} - 
> {1,-1} == {a-2,a,a+2}`.

That's the main reason why a Num instance of Sets is a bad idea. If you 
continue that way you will soon end up in MatLab mess. In MatLab every 
number is actually a complex valued matrix.

So will the next proposal be an 'instance IsString (Set a)'? Or 'instance 
IsString [a]' (for every a/=Char)?
Roman Cheplyaka | 15 Jul 19:53 2013

Re: Proposal: Add IsString instance for (Maybe a) to base

* MightyByte <mightybyte <at> gmail.com> [2013-07-15 08:26:13-0400]
> I'll just throw out a data point related to this discussion.  In one of my
> previous commercial Haskell projects we ended up writing a similar Num
> instance for Maybe a.  I think I asked about it in #haskell back then and
> got pretty vocal distaste about the idea from several people who spoke up.
>  "Maybe is not a number!"  But we did end up using the instance in our
> project because it greatly simplified a section of our code.  I'm certainly
> not going to recommend that we also add the Num instance for Maybe.  But I
> think it's a useful data point that this happened in real-world production
> code at a company where writing Haskell code was my full-time job.
> 
> As for my personal opinion on this proposal, I'm on the fence.  I can see
> how it would be nice to have this kind of convenience, but the arguments on
> the opposing side also resonate with me as well.

I don't see any contradiction here.

It's perfectly fine if you decided that you need that instance and
introduced it in your code. It would be very strange if someone said you
shouldn't do that.

I also don't mind package authors (ab)using IsString to make their
libraries more convenient to use. If someone doesn't like that library,
they doesn't have to use it.

What I am against is putting that instance into base, thus making it
impossible to opt-out.

Roman
MightyByte | 15 Jul 20:06 2013
Picon

Re: Proposal: Add IsString instance for (Maybe a) to base

On Mon, Jul 15, 2013 at 1:53 PM, Roman Cheplyaka <roma <at> ro-che.info> wrote:
I don't see any contradiction here.

It's perfectly fine if you decided that you need that instance and
introduced it in your code. It would be very strange if someone said you
shouldn't do that.

I also don't mind package authors (ab)using IsString to make their
libraries more convenient to use. If someone doesn't like that library,
they doesn't have to use it.

What I am against is putting that instance into base, thus making it
impossible to opt-out.

Yes, I agree with you.  It seems to be relatively uncommon for these specialized instances to help significantly, which means that we're not saving people that much code by including it in base.

So -1 from me.
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
John Lato | 16 Jul 02:44 2013
Picon

Re: Proposal: Add IsString instance for (Maybe a) to base

On Tue, Jul 16, 2013 at 1:53 AM, Roman Cheplyaka <roma <at> ro-che.info> wrote:
* MightyByte <mightybyte <at> gmail.com> [2013-07-15 08:26:13-0400]
> I'll just throw out a data point related to this discussion.  In one of my
> previous commercial Haskell projects we ended up writing a similar Num
> instance for Maybe a.  I think I asked about it in #haskell back then and
> got pretty vocal distaste about the idea from several people who spoke up.
>  "Maybe is not a number!"  But we did end up using the instance in our
> project because it greatly simplified a section of our code.  I'm certainly
> not going to recommend that we also add the Num instance for Maybe.  But I
> think it's a useful data point that this happened in real-world production
> code at a company where writing Haskell code was my full-time job.
>
> As for my personal opinion on this proposal, I'm on the fence.  I can see
> how it would be nice to have this kind of convenience, but the arguments on
> the opposing side also resonate with me as well.

I don't see any contradiction here.

It's perfectly fine if you decided that you need that instance and
introduced it in your code. It would be very strange if someone said you
shouldn't do that.

I also don't mind package authors (ab)using IsString to make their
libraries more convenient to use. If someone doesn't like that library,
they doesn't have to use it.

What I am against is putting that instance into base, thus making it
impossible to opt-out.

It's opt-in, not opt-out.  You opt-in by turning on OverloadedStrings.  If you don't want your strings to be other than Strings, don't enable the extension.

I get the sense that a lot of people feel OverloadedStrings really means ProperStringLiterals, and want to use the extension as a proxy for a language with String type that isn't [Char].  I don't think it's correct to co-opt a generalizing extension to try to cover up a prior issue with the language.

We probably should add a ProperStringLiterals extension, actually.
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

Gmane