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@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata@debian.org

-1 here too. On Wed, Jul 10, 2013 at 10:02 AM, David Luposchainsky < dluposchainsky@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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

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

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

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

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

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

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

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

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

...

On 10 July 2013 05:24, Simon Hengel 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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

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@haskell.org] on behalf of Henning Thielemann [lemming@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.

* MightyByte [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

On Tue, Jul 16, 2013 at 1:53 AM, Roman Cheplyaka 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'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

* MightyByte [2013-07-15 08:26:13-0400] 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.