my actual use case looks more like this: {-# LANGUAGE OverloadedStrings #-} {-# LANGUAGE FlexibleInstances, TypeSynonymInstances #-} import Data.Text as T class ShowT a where showT :: a -> String instance ShowT T.Text where showT = show instance ShowT String where showT = show main = print (showT "Hello!") Ambiguous type variable `a0' in the constraints: (ShowT a0) arising from a use of `showT' at default.hs:16:15-19 (Data.String.IsString a0) arising from the literal `"Hello!"' So I actually want to define a default instance for a typeclass I define that uses isString instances. On Sat, Apr 21, 2012 at 6:24 PM, Daniel Peebles wrote:

I think it'll be hard to do that without putting Text in base, which I'm not sure anyone wants to do.

Dan

On Sat, Apr 21, 2012 at 8:20 PM, Greg Weber wrote:

...

I would like to default IsString to use the Text instance to avoid ambiguous type errors. I see defaulting capability is available for Num. Is there any way to do this for IsString?

Thanks, Greg Weber

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

I do not think this is a bug. Since type classes are open, GHC does not do any reasoning of the form "X is the only instance in scope, so I will pick that one". Other instances could be added at any time (perhaps in other modules). In this particular instance, GHC has no reason to choose the Text instance other than the fact that it is the only instance in scope -- that is, type inference is not enough to determine that the Text instance should be chosen. However, I do agree that it would be nice to have a mechanism for specifying default instances for arbitrary (user-defined) type classes. -Brent On Sat, Apr 21, 2012 at 09:55:32PM -0700, Greg Weber wrote:

This is a better demonstration of the issue. I am going to open a GHC bug report, as I can't see how this behavior is desirable.

{-# LANGUAGE OverloadedStrings #-} import Data.Text as T

class NoDefault a where noDefault :: a -> Text instance NoDefault T.Text where noDefault = id

main = print (noDefault "Hello!")

default.hs:7:15: Ambiguous type variable `a0' in the constraints: (NoDefault a0) arising from a use of `noDefault' at default.hs:7:15-23 (Data.String.IsString a0) arising from the literal `"Hello!"' at default.hs:7:25-32 Probable fix: add a type signature that fixes these type variable(s) In the first argument of `print', namely `(noDefault "Hello!")' In the expression: print (noDefault "Hello!") In an equation for `main': main = print (noDefault "Hello!")

On Sat, Apr 21, 2012 at 7:51 PM, Greg Weber wrote:

...

my actual use case looks more like this:

{-# LANGUAGE OverloadedStrings #-} {-# LANGUAGE FlexibleInstances, TypeSynonymInstances #-}

import Data.Text as T

class ShowT a where   showT :: a -> String

instance ShowT T.Text where   showT = show

instance ShowT String where   showT = show

main = print (showT "Hello!")

   Ambiguous type variable `a0' in the constraints:      (ShowT a0) arising from a use of `showT' at default.hs:16:15-19      (Data.String.IsString a0) arising from the literal `"Hello!"'

So I actually want to define a default instance for a typeclass I define that uses isString instances.

On Sat, Apr 21, 2012 at 6:24 PM, Daniel Peebles wrote:

...

I think it'll be hard to do that without putting Text in base, which I'm not sure anyone wants to do.

Dan

On Sat, Apr 21, 2012 at 8:20 PM, Greg Weber wrote:

...

I would like to default IsString to use the Text instance to avoid ambiguous type errors. I see defaulting capability is available for Num. Is there any way to do this for IsString?

Thanks, Greg Weber

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

| Couldn't we make a special case for IsString, like we do for Num, | given it's special syntactic association with OverloadedStrings? Maybe so. It's open to anyone to make a concrete proposal. See http://hackage.haskell.org/trac/ghc/ticket/6030 which may be the same issue. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Johan Tibell | Sent: 22 April 2012 18:51 | To: Brent Yorgey | Cc: glasgow-haskell-users@haskell.org | Subject: Re: default instance for IsString | | On Sun, Apr 22, 2012 at 10:37 AM, Brent Yorgey | wrote: | > I do not think this is a bug.  Since type classes are open, GHC does | > not do any reasoning of the form "X is the only instance in scope, so | > I will pick that one".  Other instances could be added at any time | > (perhaps in other modules).  In this particular instance, GHC has no | > reason to choose the Text instance other than the fact that it is the | > only instance in scope -- that is, type inference is not enough to | > determine that the Text instance should be chosen. | > | > However, I do agree that it would be nice to have a mechanism for | > specifying default instances for arbitrary (user-defined) type | > classes. | | Couldn't we make a special case for IsString, like we do for Num, | given it's special syntactic association with OverloadedStrings? | | -- Johan | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Sorry, someone responded on haskell-cafe and the message didn't get sent here. You can default a String. So this compiles just fine: {-# LANGUAGE OverloadedStrings #-} {-# LANGUAGE ExtendedDefaultRules #-} import Data.Text as T default (T.Text) class NoDefault a where noDefault :: a -> Text instance NoDefault T.Text where noDefault = id main = print (noDefault "Hello!") On Sun, Apr 22, 2012 at 1:57 PM, Jeremy Shaw wrote:

I have often wished for something like:

{-# LANGUAGE StringLiteralsAs Text #-}

where all string literals like:

...

f = "foo"

would be translated to:

...

f = (fromString "foo" :: Text)

I find that OverloadedStrings is too general and causes ambiguous type errors. Additionally, I seldom find that I have more than one type of string literal per file. Things tend to be all String, all Text, etc. So, if I could just pick a concrete type for all the string literals in my file, I would be happy.

- jeremy

On Sat, Apr 21, 2012 at 7:20 PM, Greg Weber wrote:

...

I would like to default IsString to use the Text instance to avoid ambiguous type errors. I see defaulting capability is available for Num. Is there any way to do this for IsString?

Thanks, Greg Weber

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

On Mon, Apr 23, 2012 at 9:58 AM, Yitzchak Gale wrote:

Jeremy Shaw wrote:

...

...

I have often wished for something like:     {-# LANGUAGE StringLiteralsAs Text #-} where all string literals like:     f = "foo" would be translated to:     f = (fromString "foo" :: Text)

Agreed, I would also really like this.

...

...

I find that OverloadedStrings is too general and causes ambiguous type errors. Additionally, I seldom find that I have more than one type of string literal per file. Things tend to be all String, all Text, etc. So, if I could just pick a concrete type for all the string literals in my file, I would be happy.

In addition, OverloadedStrings is unsound. Library authors can, and do, write unsafe implementations of IsString that cause syntax errors to be caught only at run time instead of at compile time. That is the opposite of one of the most important things we are trying to accomplish by using Haskell instead of, say, some dynamically typed language.

Greg Weber wrote:

...

You can default a String. So this compiles just fine:

{-# LANGUAGE OverloadedStrings #-} {-# LANGUAGE ExtendedDefaultRules #-} import Data.Text as T default (T.Text)

No, I do not want string literals to be polymorphic, even if there is some kind of defaulting. I want them to be monomorphic, as they always have been. But I still want to be able to specify to the compiler somehow that the monomorphic type for string literals in a particular module should be something other than String.

Thanks, Yitz

Hi Yitz, I very much agree with you. However, when we complain about something essentially we are asking others to prioritize it ahead of other things. I don't think any more visibility of this issue is going to improve its prioritization. I suspect your only way forward right now is to start implementing something yourself.

On Tue, Apr 24, 2012 at 9:26 AM, Yitzchak Gale wrote:

Greg Weber wrote:

...

I very much agree with you. However, when we complain about something essentially we are asking others to prioritize it ahead of other things. I don't think any more visibility of this issue is going to improve its prioritization. I suspect your only way forward right now is to start implementing something yourself.

You're right. But as a professional Haskell developer, I am under the same kinds of deadline pressures as any other professional. So I'm afraid it's not going to be me, at least not in the near future.

However, what I can do is raise the red flag. Some people are pushing things in directions which would cause OverloadStrings to become more and more ubiquitous, perhaps even the default. I want to make sure that the people who are doing that are aware of the deep problems with that approach.

Sure, as much as anyone else, I want string literals that can be typed as Text. But not at the cost of delaying syntax checking to run time.

 And, as Bas points out, that there are many different compile time mechanisms that could be used for this.

Thanks, Yitz

Here's a theoretically simple solution to the problem. How about adding a new method to the IsString typeclass: isValidString :: String -> Bool We can give it a default implementation of `const True` for backwards compatibility. Then, whenever GHC applies OverloadedStrings in a case where the type is fully known at compile time (likely the most common case), it can run the check and- if it returns False- stop the compile. This has the benefits of letting existing code continue to work unchanged, and not requiring any Template Haskell to be involved. A downside is that it will still let invalid code through sometimes. Perhaps a solution is to modified the OverloadedStrings extension that requires that the type be fully known. If someone *really* wants polymorphic strings, they can explicitly add `fromString`. I actually think I'd prefer this version. Michael

On Tue, Apr 24, 2012 at 08:32, Michael Snoyman wrote:

Here's a theoretically simple solution to the problem. How about adding a new method to the IsString typeclass:

   isValidString :: String -> Bool

If you're going with this approach, why not evaluate the conversion from String immediately? For either case you have to know the monomorphic type, and converting at compile time is more efficient as well. But we're getting pretty close to Template Haskell here. Erik

On Tue, Apr 24, 2012 at 10:55, Michael Snoyman wrote:

On Tue, Apr 24, 2012 at 11:36 AM, Erik Hesselink wrote:

...

On Tue, Apr 24, 2012 at 08:32, Michael Snoyman wrote:

...

Here's a theoretically simple solution to the problem. How about adding a new method to the IsString typeclass:

   isValidString :: String -> Bool

If you're going with this approach, why not evaluate the conversion from String immediately? For either case you have to know the monomorphic type, and converting at compile time is more efficient as well. But we're getting pretty close to Template Haskell here.

I could be mistaken, but I think that would be much harder to implement at the GHC level. GHC would then be responsible for taking a compile-time value and having it available at runtime (i.e., lifting in TH parlance). Of course, I'm no expert on GHC at all, so if someone who actually knows what they're talking about says that this concern is baseless, I agree that your approach is better.

But GHC already has all the infrastructure for this, right? You can do exactly this with TH. Erik

On 24/04/2012 11:08, Erik Hesselink wrote:

On Tue, Apr 24, 2012 at 10:55, Michael Snoyman wrote:

...

On Tue, Apr 24, 2012 at 11:36 AM, Erik Hesselink wrote:

...

On Tue, Apr 24, 2012 at 08:32, Michael Snoyman wrote:

...

Here's a theoretically simple solution to the problem. How about adding a new method to the IsString typeclass:

isValidString :: String -> Bool

If you're going with this approach, why not evaluate the conversion from String immediately? For either case you have to know the monomorphic type, and converting at compile time is more efficient as well. But we're getting pretty close to Template Haskell here.

I could be mistaken, but I think that would be much harder to implement at the GHC level. GHC would then be responsible for taking a compile-time value and having it available at runtime (i.e., lifting in TH parlance). Of course, I'm no expert on GHC at all, so if someone who actually knows what they're talking about says that this concern is baseless, I agree that your approach is better.

But GHC already has all the infrastructure for this, right? You can do exactly this with TH.

No, Michael is right. The library writer would need to provide fromString :: String -> Q Exp since there's no way to take an aribtrary value and convert it into something we can compile. Cheers, Simon

Markus Läll wrote:

What can go wrong when you use an overloaded string to be fromString'd into Text?

Here's an example: The author of the xml-types package provides an IsString instance for XML names, so you can conveniently represent XML names as string literals in your source code. But not every string is a valid XML name. If you mistype the literal, your program will still compile. It may even run for a while. But when someone uses your program in a way that causes that mistyped XML name literal to be resolved, your program will likely crash, unless you structured it in a way that allows that XML name literal to be wrapped in an appropriate exception handler in the IO monad. -Yitz

On Mon, Apr 23, 2012 at 9:58 AM, Yitzchak Gale wrote:

In addition, OverloadedStrings is unsound.

No. OverloadedStrings treats string literals as applications of fromString to character list constants. fromString can throw errors, just like fromInteger; this is no less sound than any Haskell function throwing an exception. /g -- "Would you be so kind as to remove the apricots from the mashed potatoes?"

I wrote:

...

In addition, OverloadedStrings is unsound.

J. Garrett Morris wrote:

fromString can throw errors, just like fromInteger

This is true; the use of polymorphism for numeric literals is also unsound. However, in practice, it is rare for there to be dangerous instances of the numeric type classes.

this is no less sound than any Haskell function throwing an exception.

No. Usually, operations that can throw an exception are in the IO monad, where the specter of a potential exception is more obvious, and where the operation can be wrapped in try or catch. Whereas a string literal that might throw an exception at run time is bizarre, to say the least. And it is extremely difficult to deal with potential exceptions thrown by fundamental language syntax that is sprinkled throughout nearly every Haskell module in existence. Yitz

On Tue, Apr 24, 2012 at 02:14, J. Garrett Morris wrote:

On Mon, Apr 23, 2012 at 11:10 PM, Yitzchak Gale wrote:

...

This is true; the use of polymorphism for numeric literals is also unsound.

By this logic, head is "unsound", since head [] throws an error.

Oddly enough, it's actually widely recognized that non-total functions like `head` pose problems. it still remains that string (or indeed numeric) literals are not expected to cause runtime exceptions. -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

I'm not following the details of this thread, but if you guys can come to a conclusion and write up a design, I'd be happy to discuss it. If you want validation of literal strings, then TH quasiquotes are the way to go: [url| http://this/that |] will let you specify the parser/validator to use ("url" in this case) and allow any error messages to be delivered in a civilised way at compile time. I don't really want to make "http://this/that" have exactly this semantics; apart from anything else, which parser do you mean. This is what TH quasiquotation is *for*. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell- | users-bounces@haskell.org] On Behalf Of Yitzchak Gale | Sent: 24 April 2012 07:46 | To: J. Garrett Morris | Cc: GHC users | Subject: Re: default instance for IsString | | J. Garrett Morris wrote: | > By this logic, head is "unsound", since head [] throws an error. | > Haskell types are pointed; Haskell computations can diverge. | | Well, there are those who would actually agree with that and banish 'head' | and friends from the language. | But I'll agree with you here. | | [As an aside - I'm finding that liberal use of Edward's non-empty list type, | found in the semigroups package, solves many of those problems for me.] | | But there are two crucial differences. First, head is just a partial | function, not basic language syntax. | Second, the divergence of head is constant and well-known, and not dependent | on the implementation of a type class at particular types by various library | authors. | | >  What happens after the computation diverges is irrelevant to type | > soundness. | | Agreed. I'm not talking about type soundness, in the technical sense. I'm | talking about engineering soundness. | | Thanks, | Yitz | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

You do know, that you already *can* have safe Text and ByteString from an overloaded string literal. On Tue, Apr 24, 2012 at 11:46 AM, Yitzchak Gale wrote:

Simon Peyton-Jones wrote:

...

If you want validation of literal strings, then TH quasiquotes are the way to go:

I agree. OverloadedStrings is, in effect, an unsafe replacement for quasiquotes. People find OverloadedStrings easier to use than quasiquotes, so its use in that way is becoming popular.

What we need is a mechanism for allowing string literals to have the type Text or ByteString instead of String.

I do not want to be forced to turn on UnsafeQuasiQuotes every time I need a string literal. So in my opinion, OverloadedStrings is the wrong mechanism for providing Text and ByteString literals.

Alternatives that have been suggested:

o A hard-coded pragma to specify the type of string literals in a module as Text or ByteString.

o An extra method of IsString, of type QuasiQuoter, that runs at compile time in a monomorphic context.

o As above, but only check syntax at compile time in a monomorphic context. That allows a simpler API, without requiring any TH knowledge in most cases.

Thanks, Yitz

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

-- Markus Läll

On Tue, Apr 24, 2012 at 12:35 PM, Yitzchak Gale wrote:

Markus Läll wrote:

...

You do know, that you already *can* have safe Text and ByteString from an overloaded string literal.

Yes, the IsString instances for Text and ByteString are safe (I hope).

But in order to use them, I have to turn on OverloadedStrings. That could cause other string literals in the same module to throw exceptions at run time.

-Yitz

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Actually, the ByteString instance is arguably unsafe as well: {-# LANGUAGE OverloadedStrings #-} import qualified Data.ByteString.Char8 as S8 main = S8.putStrLn "שלום" It would be nice if usage of characters outside of the 0-255 range could be caught at compile time. Michael

Why are potentially partial literals scarier than the fact that every value in the language could lead to an exception when forced? On Tue, Apr 24, 2012 at 5:35 AM, Yitzchak Gale wrote:

Markus Läll wrote:

...

You do know, that you already *can* have safe Text and ByteString from an overloaded string literal.

Yes, the IsString instances for Text and ByteString are safe (I hope).

But in order to use them, I have to turn on OverloadedStrings. That could cause other string literals in the same module to throw exceptions at run time.

-Yitz

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Simon Marlow wrote:

In this thread people are using the term "safe" to mean "total".  We already overload "safe" too much, might it be a better idea to use "total" instead?

I'm not sure what you're talking about. I don't see how this thread has anything to do with total vs. partial functions. I'm saying that the static syntax of string literals should be checked at compile time, not at run time. Isn't that simple enough, and self-evident? Thanks, Yitz

Hi Simon, First of all, I'm sorry if I'm coming off as too combative, as Greg says. That is certainly not my intention. I'm not asking for any free work from you, either. The only reason I don't like using OverloadedStrings for typing string literals as Text and ByteString is that when you turn on OverloadedStrings, you turn it on for all types, not just Text and ByteString. I don't want to be forced to do that. Because all other uses of OverloadedStrings that I have seen, and there are many, are ill-advised in my opinion. They all should have been quasiquoters. If it's really important to use this mechanism for typing string literals as Text and ByteString, how about this: Create a new class IsBuiltinString, with method isBuiltinString. Make it hidden so that no new instances can be defined outside of base, and provide instances only for String, Text, and ByteString, for now. Then I will happily use the OverloadedBuiltinStrings extension. People who don't see any problem with OverloadedStrings can go on using it as before. Thanks, Yitz

Erik Hesselink wrote:

I don't think IsString should be dismissed so easily.

I'm just saying I don't want to be forced to use it. If others like it, I'm not dismissing it.

we have a couple of newtypes over Text that do different kinds of normalization. An IsString instance for these is useful and total.

True. Perhaps you'd be able to get IsBuiltinString instances for those too, using newtype deriving, if only the method names of IsBuiltinString are hidden and the class name is exported. If that doesn't work, I'm fine with using a quasiquoter for those instead. Or even just the usual newtype unwrapping and wrapping. And again, if you provide IsString and others want to use it, that's fine. Thanks, Yitz

On April 25, 2012 04:15:41 Yitzchak Gale wrote:

The only reason I don't like using OverloadedStrings for typing string literals as Text and ByteString is that when you turn on OverloadedStrings, you turn it on for all types, not just Text and ByteString. I don't want to be forced to do that. Because all other uses of OverloadedStrings that I have seen, and there are many, are ill-advised in my opinion. They all should have been quasiquoters.

Maybe what you really want is the ability to control instance imports? Is there a technical reason this couldn't be done? The Haskell report only says doing this is not part of haskell. It doesn't say why. Cheers! -Tyson

On April 25, 2012 12:20:16 Johan Tibell wrote:

On Wed, Apr 25, 2012 at 8:19 AM, Tyson Whitehead wrote:

...

Is there a technical reason this couldn't be done? The Haskell report only says doing this is not part of haskell. It doesn't say why.

I think the problem is incoherence, what if the same Map value got used with two different instances of Int?

I'm not sure I follow how allowing control over importing of instances could allow a programmer to define multiple instances for the same types. I would have expected this to result in a link time error as a product of multiple declerations (something like a multiple symbol definition) regardless of whether any module brings it into scope as a possible candidate for use. Cheers! -Tyson

Hi, Am Mittwoch, den 25.04.2012, 11:15 +0300 schrieb Yitzchak Gale:

The only reason I don't like using OverloadedStrings for typing string literals as Text and ByteString is that when you turn on OverloadedStrings, you turn it on for all types, not just Text and ByteString. I don't want to be forced to do that. Because all other uses of OverloadedStrings that I have seen, and there are many, are ill-advised in my opinion. They all should have been quasiquoters.

another option, quick idea from a pub: Make OverloadedStrings work with re-bindable syntax (←needs GHC change, probably) and redefine fromString as you want. E.g, if you want to use alwas Text, just define fromText :: String -> Text in your module (and do not import the IsString method). Greetings, Joachim -- Joachim "nomeata" Breitner mail@joachim-breitner.de | nomeata@debian.org | GPG: 0x4743206C xmpp: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/

Daniel Peebles wrote:

Why are potentially partial literals scarier than the fact that every value in the language could lead to an exception when forced?

That's a legitimate question, but it's strange to hear it from you. People ask that same question about Haskell's static type system. Why bother? Every value could lead to an exception when forced. So we might as well check everything at run time. Wouldn't it be ironic if the one thing that every language other than Haskell is able to check at compile time, namely the static syntax of string literals, could only be checked at run time in Haskell? Especially when, with just a little care, we could easily continue to check it at compile time while still supporting string literals of type Text and ByteString. I guess I'm just not understanding your question. Thanks, Yitz

From what I can see the core of the disagreement is that some people believe fromString will tempt misuse (i.e. using *easily* partial functions, like XML validation), while others don't think it's that likely. Indeed misusing IsString is worse than your average partial function because of the global nature of typeclasses and fromString being implicit. If that is indeed the core of the disagreement, then can we at least agree that writing a partial fromString is a bad idea? I'd say *easily* partial since someone pointed out the UTF8 fromString is partial, but it's pretty hard to type bad UTF8 accidentally so it doesn't seem so bad to me.

If we agree that 'fromString :: String -> XML' is a bad idea, then can we just say "so don't do that then"? Safety is good but there's a point where you have to trust people with the sharp tools. Suppose a library author adding a fromString for regexes that crashes on unbalanced parens. If it's a problem in practice I imagine people would complain to them to change their library, or use another library. On Tue, Apr 24, 2012 at 9:10 AM, Henrik Nilsson wrote:

Hi,

Yitzhack Gale wrote:

...

Wouldn't it be ironic if the one thing that every language other than Haskell is able to check at compile time, namely the static syntax of string literals, could only be checked at run time in Haskell?

I don't really see the irony, I'm afraid, as nothing really has changed, and as Simon M. that I don't see what the fuss is about.

Presumably, the syntax of string literals as such is still going to be checked by the scanner, as it always was? And the issue, then, is whether an overloaded "fromString" is total in all its overloadings? Or did I miss something central, here?

Well, Haskell is not a total language, so the fact that "fromString" might have non-total overloadings is not surprising. Yes, "fromString" would be implicitly inserted, just like e.g. "fromInteger" for overloaded integer literals, to create the effect of overloaded literals, but this is really just a convenience, albeit an important one.

The benefit of an approach to overloading of string literals that is analogous to the existing method for overloading of numeric literals would seem to me to outweigh the benefits of additional static checking through an essentially new approach to overloading of literals for a specific case.

Best,

/Henrik

-- Henrik Nilsson School of Computer Science The University of Nottingham nhn@cs.nott.ac.uk

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

So if every value, when forced, can crash your program, possibly depending on what type it's instantiated to, why are we so concerned about String literals behaving like everything else?

Well, that was exactly my point. Some people think it's *more likely* that people will write crashing fromString methods.

On 4/24/12 3:35 PM, Markus Läll wrote:

For what I understand, and putting words in his mouth, he wants to write `"" :: XML' and have the compiler tell him at compile-time that this is not valid XML (if it actually is, imagine that there's something invalid between the double quotes). I.e he wants to parse the string at compile-time and have the compilation fail if the parse fails, or have the string literal be replaced by the syntax tree of that XML if it succeeds.*

This example is meta-programming par excellence, which is what Template Haskell is for -- use it.

Indeed. Asking that "illegal" string literals be caught at compile time is, in effect, updating the syntax of Haskell itself. As it stands, Haskell has a definition of what a string literal is (see the Report), and whether or not that literal can be successfully coerced into a given type is neither here nor there; just as for numeric literals. I'm all for static-checking. (Even moreso with every passing year.) But if you want to make up new sorts of literals and have them checked for validity, that's exactly what quasiquotes are there for. Since you are altering the syntax of Haskell, rather than accepting what Haskell calls strings, then this is metaprogramming and so you're going to need TH, QQ, or some similar metaprogramming facility. Whereas for ByteString and Text the goal is specifically to serve as an efficient/correct replacement for String; thus, overloading string literals to support those types is _not_ asking to change the syntax of Haskell. To the extent that ByteString's instance runs into issues with high point codes, that strikes me as a bug in virtue of poor foresight. Consider, for instance, the distinction between integral and non-integral numeric literals. We recognize that (0.1 :: Int) is invalid, and so we a-priori define the Haskell syntax to recognize two different sorts of "numbers". It seems that we should do the same thing for strings. 'String' literals of raw binary goop (subject to escape mechanisms for detecting the end of string) are different from string literals which are valid Unicode sequences. This, I think, is fair game to be expressed directly in the specification of overloaded string literals, just as we distinguish classes of overloaded numeric literals. Unfortunately, for numeric literals we have a nice syntactic distinction between integral and non-integral, which seems to suggest that we'd need a similar syntactic distinction to recognize the different sorts of string literals. -- Live well, ~wren

One can always use a Maybe to make an IsString literal total. Perhaps this is what library authors should do in those cases when a fromString implementation is obviously partial. i.e. instead of instance IsString XML where ... define: instance IsString (Maybe XML) where ... HTH, Ozgur On 24 April 2012 15:03, Yitzchak Gale wrote:

Daniel Peebles wrote:

...

Why are potentially partial literals scarier than the fact that every value in the language could lead to an exception when forced?

That's a legitimate question, but it's strange to hear it from you.

People ask that same question about Haskell's static type system. Why bother? Every value could lead to an exception when forced. So we might as well check everything at run time.

Wouldn't it be ironic if the one thing that every language other than Haskell is able to check at compile time, namely the static syntax of string literals, could only be checked at run time in Haskell? Especially when, with just a little care, we could easily continue to check it at compile time while still supporting string literals of type Text and ByteString.

I guess I'm just not understanding your question.

Thanks, Yitz

The defaulting is very good for most use cases, however I am discovering it won't default when I try to build up a list or tuple. This does not work: {-# LANGUAGE OverloadedStrings #-} {-# LANGUAGE ExtendedDefaultRules #-} {-# LANGUAGE FlexibleInstances #-} module Default (noDefault) where import Data.Text as T default (T.Text) class NoDefault a where noDefault :: a -> [Text] instance NoDefault [T.Text] where noDefault = id main = print (noDefault ["Hello!"]) On Sun, Apr 22, 2012 at 8:31 PM, Greg Weber wrote:

Sorry, someone responded on haskell-cafe and the message didn't get sent here. You can default a String. So this compiles just fine:

{-# LANGUAGE OverloadedStrings #-} {-# LANGUAGE ExtendedDefaultRules #-} import Data.Text as T default (T.Text)

class    NoDefault a      where noDefault :: a -> Text instance NoDefault T.Text where noDefault = id

main = print (noDefault "Hello!")

On Sun, Apr 22, 2012 at 1:57 PM, Jeremy Shaw wrote:

...

I have often wished for something like:

{-# LANGUAGE StringLiteralsAs Text #-}

where all string literals like:

...

f = "foo"

would be translated to:

...

f = (fromString "foo" :: Text)

I find that OverloadedStrings is too general and causes ambiguous type errors. Additionally, I seldom find that I have more than one type of string literal per file. Things tend to be all String, all Text, etc. So, if I could just pick a concrete type for all the string literals in my file, I would be happy.

- jeremy

On Sat, Apr 21, 2012 at 7:20 PM, Greg Weber wrote:

...

I would like to default IsString to use the Text instance to avoid ambiguous type errors. I see defaulting capability is available for Num. Is there any way to do this for IsString?

Thanks, Greg Weber

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users