GHC 7.8.1 released • Hacker News Board

Re: GHC 7.8.1 released

#101

Post by tvon » Thu, Apr 10, 2014, 8:42 PM UTC

tvon wrote: post #99

maxpow4h wrote: post #14

Earlier quoted context omitted.

the twitter app is 30M, we have already past the point of sensible app sizes. edit: fb messenger is 60M, a ghc-ios app with the elm compiler baked in is 24M.

To me that makes it clear that a minimum size of over 20M is a serious problem. How crazy would it be if the Twitter app was over 50M, or Facebook Messenger over 80M?

(I should not have said "serious problem", I should have said "notable barrier to adoption." That people have made this possible at all is fantastic.)

Re: GHC 7.8.1 released

#102

Post by chongli » Fri, Apr 11, 2014, 2:43 PM UTC

tel wrote: post #100

chongli wrote: post #98

Earlier quoted context omitted.

When you use OverloadedStrings in conjunction with Data.ByteString.Char8 it becomes OverloadedStrings' issue as well. Compile-time transformations are not supposed to break your program.

I don't think of it as a compile-time transformation but instead a weakening of the semantics of string literals. Without we have "foo" :: String and with we have "foo" :: IsString a => a much like 3 :: Num a => a It inherits all of the same weaknesses and strengths that we have with the Num typeclass.

Ahh, very good. Then perhaps our target of inquiry ought to be the IsString class. Ought it have some laws we can expect instances to follow, akin to the Monad laws? At the moment, we can write:

    instance IsString () where
    fromString = const ()

And there's nothing wrong with it!

Re: GHC 7.8.1 released

#103

Post by tel » Fri, Apr 11, 2014, 5:15 PM UTC

chongli wrote: post #102

tel wrote: post #100

Earlier quoted context omitted.

I don't think of it as a compile-time transformation but instead a weakening of the semantics of string literals. Without we have "foo" :: String and with we have "foo" :: IsString a => a much like 3 :: Num a => a It inherits all of the same weaknesses and strengths that we have with the Num typeclass.

Ahh, very good. Then perhaps our target of inquiry ought to be the IsString class. Ought it have some laws we can expect instances to follow, akin to the Monad laws? At the moment, we can write: instance IsString () where fromString = const () And there's nothing wrong with it!

Totally agree that it's a weak class. I'd love it if `IsList` were a subclass of `Foldable`!