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
On 22/04/2012, AntC wrote:
> Matthew Farkas-Dyck gmail.com> writes:
>
>> I made another proposal for records in Haskell, meant to solve just
>> the namespace problem, and no more.
>> http://hackage.haskell.org/trac/ghc/wiki/Records/ExplicitClassyRecords
>>
>
> Thanks Matthew, I'm finding your wik
12 matches
Mail list logo
