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 Wed, Apr 25, 2012 at 10:15, Yitzchak Gale g...@sefer.org 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
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
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
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
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.
On Wed, Apr 25, 2012 at 8:19 AM, Tyson Whitehead twhiteh...@gmail.com 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
From: Yitzchak Gale g...@sefer.org
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.
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
On Wed, Apr 25, 2012 at 11:39 AM, Ozgur Akgun ozgurak...@gmail.com 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
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
On April 25, 2012 12:20:16 Johan Tibell wrote:
On Wed, Apr 25, 2012 at 8:19 AM, Tyson Whitehead twhiteh...@gmail.com
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
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, you turn
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
On Mon, Apr 23, 2012 at 11:10 PM, Yitzchak Gale g...@sefer.org 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
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
On Tue, Apr 24, 2012 at 02:14, J. Garrett Morris jgmor...@cs.pdx.eduwrote:
On Mon, Apr 23, 2012 at 11:10 PM, Yitzchak Gale g...@sefer.org 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.
On Tue, Apr 24, 2012 at 9:26 AM, Yitzchak Gale g...@sefer.org 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
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
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 common
On Tue, Apr 24, 2012 at 9:26 AM, Yitzchak Gale g...@sefer.org 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
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
| -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 IsString
|
| J. Garrett Morris wrote
I see what you mean -- many libraries provide conveniences like that
(like TagSoups `takeWhile (~== /a) 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
On Tue, Apr 24, 2012 at 08:32, Michael Snoyman mich...@snoyman.com 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
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 11:36 AM, Erik Hesselink hessel...@gmail.com wrote:
On Tue, Apr 24, 2012 at 08:32, Michael Snoyman mich...@snoyman.com wrote:
Here's a theoretically simple solution to the problem. How about
adding a new method to the IsString typeclass:
isValidString :: String -
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 g...@sefer.org wrote:
Simon Peyton-Jones wrote:
If you want validation of literal strings, then TH quasiquotes are the way
to go:
I agree.
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
On Tue, Apr 24, 2012 at 12:35 PM, Yitzchak Gale g...@sefer.org 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
On Tue, Apr 24, 2012 at 10:55, Michael Snoyman mich...@snoyman.com wrote:
On Tue, Apr 24, 2012 at 11:36 AM, Erik Hesselink hessel...@gmail.com wrote:
On Tue, Apr 24, 2012 at 08:32, Michael Snoyman mich...@snoyman.com wrote:
Here's a theoretically simple solution to the problem. How about
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
On Tue, Apr 24, 2012 at 1:08 PM, Erik Hesselink hessel...@gmail.com wrote:
On Tue, Apr 24, 2012 at 10:55, Michael Snoyman mich...@snoyman.com wrote:
On Tue, Apr 24, 2012 at 11:36 AM, Erik Hesselink hessel...@gmail.com wrote:
On Tue, Apr 24, 2012 at 08:32, Michael Snoyman mich...@snoyman.com
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 g...@sefer.org wrote:
Markus Läll wrote:
You do know, that you already *can* have safe Text and ByteString from
On 24/04/2012 11:08, Erik Hesselink wrote:
On Tue, Apr 24, 2012 at 10:55, Michael Snoymanmich...@snoyman.com wrote:
On Tue, Apr 24, 2012 at 11:36 AM, Erik Hesselinkhessel...@gmail.com wrote:
On Tue, Apr 24, 2012 at 08:32, Michael Snoymanmich...@snoyman.com wrote:
Here's a theoretically
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 much,
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
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
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 anything to do
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
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
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
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 `something=illegal :: XML' and have the compiler tell him at
compile-time that this is not
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
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
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
On Mon, Apr 23, 2012 at 9:58 AM, Yitzchak Gale g...@sefer.org 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
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 g...@sefer.org 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
On 23 April 2012 20:34, J. Garrett Morris jgmor...@cs.pdx.edu wrote:
On Mon, Apr 23, 2012 at 9:58 AM, Yitzchak Gale g...@sefer.org wrote:
In addition, OverloadedStrings is unsound.
No. OverloadedStrings treats string literals as applications of
fromString to character list constants.
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
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
On Sun, Apr 22, 2012 at 10:37 AM, Brent Yorgey byor...@seas.upenn.edu 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
| -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 IsString
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
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 -
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
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
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 g...@gregweber.info wrote:
I would like to default IsString to use the Text instance to avoid
ambiguous type errors.
I see defaulting
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 =
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 =
61 matches
Mail list logo
