Hi,
Am Mittwoch, den 25.04.2012, 21:57 +0100 schrieb Joachim Breitner:
> 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, yo
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 i
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
On Wed, Apr 25, 2012 at 11:39 AM, Ozgur Akgun wrote:
> 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
> 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 OverloadedString
> From: Yitzchak Gale
>
> 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
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
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 th
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 usefu
Hi,
On 04/25/2012 09:15 AM, Yitzchak Gale wrote:
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.
But the problem here is that reasonable people may choose to
disagree as to what is ill-advi
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 Apri
On Wed, Apr 25, 2012 at 10:15, 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
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 o
On 12-04-24 10:11 PM, wren ng thornton wrote:
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 :
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
> 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 fr
I'm the one arguing in defense of the current state of
OverloadedStrings, and no secret that Yitz has been the main opponent
of it.
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
I think my point was more along the lines that every *value*, regardless of
whether it's a function or not, can be partial (ignoring primitive types
and such). I can hand you a list where the third Int in it will cause you
to crash if you force it.
In that sense, whether every numeric literal expa
>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 gl
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
On 24/04/2012 15:19, Yitzchak Gale wrote:
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 anythin
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
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 b
On 24/04/2012 14:14, 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?
My thoughts exactly. In this thread people are using the term "safe" to
mean "total". We already overload "safe" too
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
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 overlo
On Tue, Apr 24, 2012 at 1:08 PM, 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 abo
But if you want a string to be, say, an XML document then you want to
turn the string literal into an XML syntax tree (which is correct by
the definition of the data types representing it). As this conversion
can fail (all unicode strings are not valid representations of an XML
syntax tree), you ne
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:
>>>
>>>
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 t
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
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. OverloadedS
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 t
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
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 immediat
I see what you mean -- many libraries provide conveniences like that
(like TagSoups `takeWhile (~== "") tags' and so on). But that's
the inherent mismatch between a String-- a unicode literal --and
whatever else you want it to be, be it ASCII or bash or XML or
something else.. I think the answer to
TH
quasiquotation is *for*.
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-
| users-boun...@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 Is
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
On Tue, Apr 24, 2012 at 9:26 AM, Yitzchak Gale wrote:
> 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 doi
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
> ...whenever GHC applies OverloadedStrings in a case
> where the type is fully known at compile time (likely the most comm
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
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 i
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
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
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.
Haskell types are pointed; Haskell computations can diverge. What
happens after the computation
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 typ
On 23 April 2012 20:34, J. Garrett Morris wrote:
> 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,
> jus
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 f
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
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,
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
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)
classNoDefault a where noDefault :: a -> Te
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
e issue.
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-users-
| boun...@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 IsS
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). I
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 Tex
so how can I update the documentation? I asked some of the most
experienced Haskell users at the Hackathon about this, and looked
through any documentation I could find and there was nothing
indicating I could do what you sent in your last message.
On Sun, Apr 22, 2012 at 8:15 AM, Markus Läll wro
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
classNoDefault a where noDefault :: a -> Text
instance NoDefault T.Text where noDefault = id
main =
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 =
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 f
Pretty sure it does default to String, anyway:
{-# LANGUAGE OverloadedStrings #-}
main = print (show "Hello!")
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
61 matches
Mail list logo
