February 2015 - Haskell-Cafe

SmallCheck Depth
by Omari Norman 11 Feb '15

11 Feb '15

The original SmallCheck paper [0] gives a type data Name = P | Q | R and states that all values of type Name have depth 0. To me this suggests that all values of type Bool would have depth 0 as well, seeing as Bool would simply be data Bool = True | False Sure enough, if I load up ghci with SmallCheck 0.2.1, I get > series 0 :: [Bool] [True, False] But in QuickCheck 1.1.1 I get > list 0 series :: [Bool] [] Very puzzling to me is that it seems the definition of series for Bool has not changed in the new version. Both versions have something like series = cons0 True \/ cons0 False So what explains the different behavior? Thanks. --Omari [0] http://www.cs.york.ac.uk/fp/smallcheck/smallcheck.pdf

4 7

Re: [Haskell-cafe] [Haskell] Rank-N types with (.) composition
by Henning Thielemann 11 Feb '15

11 Feb '15

On Wed, 11 Feb 2015, Simon Peyton Jones wrote: > ($) has its own *typing rule*; it does not have a special type. It's > very ad hoc, but ($) is used so much to decrease parens that (e1 $ e2) > is almost special syntax! I already wondered why runST $ do foo bar worked in some versions of GHC and not in others. I guess it is better to tell the programmer the truth, i.e. remove the special treatment of ($). If you save a programmer from wondering about why "runST $ do ... " does not work with the special typing rule for ($), the programmer will later wonder why (.) does not work or why his privately defined function application operator (e.g. for reversed order of argument and function) will not work. I think that I stay with "runST (do ...)" in order to be compatible with several GHC versions.

1 0

Re: [Haskell-cafe] [Haskell] Rank-N types with (.) composition
by Henning Thielemann 11 Feb '15

11 Feb '15

On Tue, 10 Feb 2015, Tyson Whitehead wrote: > I came across something that seems a bit strange to me. Here is a > simplified version (the original was trying to move from a lens > ReifiedFold to a lens-action ReifiedMonadicFold) You are on Haskell(a)haskell.org here. Could you please move to haskell-cafe?

1 0

stuck at the first part of chapter 1 of the CIS course
by Roelof Wobben 10 Feb '15

10 Feb '15

4 4

Using Haskell types in a database
by Nikita Karetnikov 10 Feb '15

10 Feb '15

Suppose I need to represent a user in a database. I could make a table like this one (using Yesod's config/models syntax): User name Text email Text Maybe is_verified Bool default=false last_login UTCTime default=now() Instead, it would be better to do the following, so I couldn't swap name and email by accident or feed a wrong value to is_verified and last_login: User name UserName email UserEmail v Maybe last_login UserLastLogin where newtype UserName = UserName Text deriving (Show, Read) derivePersistField "UserName" newtype UserLastLogin = UserLastLogin UTCTime deriving (Show, Read) derivePersistField "UserLastLogin" data Verified data Unverified newtype UserEmail v = UserEmail Text deriving (Show, Read) derivePersistField "UserEmail" (So I could define functions like sendAnnouncement :: UserEmail Verified -> IO () sendVerification :: UserEmail Unverified -> IO ()) The Haskell part is not new and has been successfully used in the large (see http://code.haskell.org/~dons/talks/dons-google-2015-01-27.pdf, pp. 17--21), but I wonder whether it's reasonable in the database layer. The first table will be mapped to this in PostgreSQL: User name character varying not null email character varying is_verified boolean not null default false last_login timestamp with time zone not null default now() while the second will use character varying for everything. The only downsides of the latter approach I can think of: 1. You can no longer rely on the database to ensure (basic) type safety, so everything needs to be done in the Haskell layer. Otherwise, you will get runtime errors. 2. I haven't benchmarked this, but I assume that comparing, say, booleans should be faster than comparing varchars. So, is it worth it in practice? Do I need to worry about these issues? And are there any other problems?

4 7

Injective type families for GHC
by Jan Stolarek 10 Feb '15

10 Feb '15

Haskellers, I am finishing work on adding injective type families to GHC. I know that in the past many people have asked for this feature. If you have use cases for injective type families I would appreciate if you could show them to me. My implementation has some restrictions and I want to see how severe these restrictions are from a practical point of view. Janek --- Politechnika Łódzka Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

3 5

Use of STM in business?
by Tom Ellis 10 Feb '15

10 Feb '15

>From associate of mine: "I am quite curious if anyone actually uses Haskell (esp STM) successfully in business." Of course I can anwser the general question about usage of Haskell in business, but I don't know much about STM specifically. Can anyone provide me with any references to where STM has been used in production in a business setting? Thanks, Tom

8 8

GHC 7.10 Prelude: we need your opinion
by Simon Peyton Jones 10 Feb '15

10 Feb '15

Haskell Friends This email asks for your help in deciding how to proceed with some Prelude changes in GHC 7.10. Please read on, but all the info is also at the survey link, here: http://goo.gl/forms/XP1W2JdfpX. Deadline is 21 Feb. The Core Libraries Committee (CLC) is responsible for developing the core libraries that ship with GHC. This is an important but painstaking task, and we owe the CLC a big vote of thanks for taking it on. For over a year the CLC has been working on integrating the Foldable and Traversable classes (shipped in base in GHC 7.8) into the core libraries, and into the Prelude in particular. Detailed planning for GHC 7.10 started in the autumn of 2014, and the CLC went ahead with this integration. Then we had a failure of communication. As these changes affect the Prelude, which is in scope for all users of Haskell, these changes should be held to a higher bar than the regular libraries@ review process. However, the Foldable/Traversable changes were not particularly well signposted. Many people have only recently woken up to them, and some have objected (both in principle and detail). This is an extremely unfortunate situation. On the one hand we are at RC2 for GHC 7.10, so library authors have invested effort in updating their libraries to the new Prelude. On the other, altering the Prelude is in effect altering the language, something we take pretty seriously. We should have had this debate back in 2014, but here we are, and it is unproductive to argue about whose fault it is. We all share responsibility. We need to decide what to do now. A small group of us met by Skype and we've decided to do this: · Push back GHC 7.10's release by at least a month, to late March. This delay also gives us breathing space to address an unrelated show-stopping bug, Trac #9858. · Invite input from the Haskell community on which of two approaches to adopt (this survey<http://goo.gl/forms/XP1W2JdfpX>). The main questions revolve around impact on the Haskell ecosystem (commercial applications, teaching, libraries, etc etc), so we want to ask your opinion rather than guess it. · Ask Simon Marlow and Simon Peyton Jones to decide which approach to follow for GHC 7.10. Wiki pages have been created summarizing these two primary alternatives, including many more points and counter-points and technical details: · Overall summary: https://ghc.haskell.org/trac/ghc/wiki/Prelude710<https://www.google.com/url?q=https%3A%2F%2Fghc.haskell.org%2Ftrac%2Fghc%2Fw…> · Details of Plan List: https://ghc.haskell.org/trac/ghc/wiki/Prelude710/List<https://www.google.com/url?q=https%3A%2F%2Fghc.haskell.org%2Ftrac%2Fghc%2Fw…> · Details of Plan FTP: https://ghc.haskell.org/trac/ghc/wiki/Prelude710/FTP<https://www.google.com/url?q=https%3A%2F%2Fghc.haskell.org%2Ftrac%2Fghc%2Fw…> This survey invites your input on which plan we should follow. Would you please · Read the details of the alternative plans on the three wiki pages above · Add your response to the survey<http://goo.gl/forms/XP1W2JdfpX> Please do read the background. Well-informed responses will help. Thank you! DEADLINE: 21 February 2015 Simon PJ

2 2

How does RTS judge that a STM transaction is blocked?
by Magicloud Magiclouds 10 Feb '15

10 Feb '15

Hi, I met an issue while I was using xhb. When a certain property of root window being changed, it was supposed to give me an AccessError. But actually I got "thread blocked indefinitely in an STM transaction" when I waitForEvent. AFAIK, in xhb, it forks a thread to read what X server sends. Then parse and put it into a TChan. waitForEvent reads from the TChan. It is reasonable to me that if X server did not send anything, then waitForEvent would be blocked. But apparently there are some other policies in RTS. So what is that? And how should I debug it? -- 竹密岂妨流水过山高哪阻野云飞 And for G+, please use magiclouds#gmail.com.

3 5

GHC-7.8.4 for Mac OS X
by Ozgur Akgun 09 Feb '15

09 Feb '15

Hi, Does anyone plan to put a binary release of GHC-7.8.4 for OS X? There isn't one here: https://www.haskell.org/ghc/download_ghc_7_8_4 Cheers! Ozgur

3 2