default instance for IsString

[Greg Weber]

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
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Christopher Done]

Pretty sure it does default to String, anyway:

{-# LANGUAGE OverloadedStrings #-}

main = print (show "Hello!")

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Daniel Peebles]

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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Greg Weber]

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 <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Greg Weber]

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>> [hidden email]
>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>>

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Greg Weber]

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 <[hidden email]> wrote:

> The core of it is in the GHC docs' overloaded strings section [1].
>
> It could be clearer though -- reading about defaulting in the reports,
> in the type defaulting section of GHC docs and in [1] can be a bit
> confusing.
>
> [1] http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensions.html#overloaded-strings
>
> On Sun, Apr 22, 2012 at 4:54 PM, Greg Weber <[hidden email]> wrote:
>> Thanks Markus, I think you have saved the day!
>> Even after googling for this extension and searching in the manual I
>> am still coming up pretty blank.
>> Is there somewhere I missed where this is documented or somewhere I
>> can contribute documentation?
>>
>> On Sun, Apr 22, 2012 at 4:47 AM, Markus Läll <[hidden email]> wrote:
>>> ExtendedDefaultRules
>
>
>
> --
> Markus Läll

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Brent Yorgey-2]

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> >>> [hidden email]
> >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> >>
> >>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Johan Tibell-2]

On Sun, Apr 22, 2012 at 10:37 AM, Brent Yorgey <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Simon Peyton-Jones]

|  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: [hidden email] [mailto:glasgow-haskell-users-
|  [hidden email]] On Behalf Of Johan Tibell
|  Sent: 22 April 2012 18:51
|  To: Brent Yorgey
|  Cc: [hidden email]
|  Subject: Re: default instance for IsString
|  
|  On Sun, Apr 22, 2012 at 10:37 AM, Brent Yorgey <[hidden email]>
|  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
|  [hidden email]
|  http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Jeremy Shaw-3]

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 <[hidden email]> 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
> [hidden email]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Greg Weber]

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 <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Yitzchak Gale]

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

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Greg Weber]

On Mon, Apr 23, 2012 at 9:58 AM, Yitzchak Gale <[hidden email]> 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.

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Greg Weber]

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>> [hidden email]
>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[J. Garrett Morris-3]

On Mon, Apr 23, 2012 at 9:58 AM, Yitzchak Gale <[hidden email]> 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?"

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Bas van Dijk-2]

On 23 April 2012 20:34, J. Garrett Morris <[hidden email]> wrote:
> On Mon, Apr 23, 2012 at 9:58 AM, Yitzchak Gale <[hidden email]> 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.

But it would be safer if those errors were moved to compile time by
treating overloaded literals as Template Haskell splices. As in:

1

would be translated to:

$(fromIntegerLit 1)

where:

class FromIntegerLit a where
  fromIntegerLit :: Integer -> Q (Exp a)

(this assumes that Exp is parameterized by the type of the value it
splices to which is currently not the case. However you can work
around this by using a Proxy or Tagged value.)

An instance for Integer is trivial:

instance FromIntegerLit Integer where
  fromIntegerLit = litE . integerL

The extra safety comes when giving an instance for natural numbers, for example:

newtype Nat = Nat Integer

instance FromIntegerLit Nat where
  fromIntegerLit n
      | n < 0     = error "Can't have negative Nats"
      | otherwise = 'Nat `appE` fromIntegerLit n

Note that the error will be thrown at compile time when the user has
written a negative Nat literal.

Regards,

Bas

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Yitzchak Gale]

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

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[J. Garrett Morris-3]

On Mon, Apr 23, 2012 at 11:10 PM, Yitzchak Gale <[hidden email]> 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 diverges is irrelevant to type soundness.

 /g


--
"Would you be so kind as to remove the apricots from the mashed potatoes?"

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Yitzchak Gale]

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

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Brandon Allbery]

On Tue, Apr 24, 2012 at 02:14, J. Garrett Morris <[hidden email]> wrote:

On Mon, Apr 23, 2012 at 11:10 PM, Yitzchak Gale <[hidden email]> 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                                      [hidden email]
wandering unix systems administrator (available)     [phone] vm/sms

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users