- Haskell-Cafe - Haskell.org

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

11 Feb '15

On 11/02/15 04:39 AM, 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 do like the idea of being able to end a function application with a lambda, let, if, case, or do without having to use $ though. Would something like the following grammar rules be problematic for parsing? infixexp→ lexp qop infixexp | - infixexp | [fexp] lexp (*) | aexp (*) lexp → \ apat1 … apatn -> exp | let decls in exp | if exp [;] then exp [;] else exp | case exp of { alts } | do { stmts } (*) fexp → [fexp] aexp aexp → qvar | gcon | literal | ( exp ) | ( exp1 , … , expk ) | [ exp1 , … , expk ] | [ exp1 [, exp2] .. [exp3] ] | [ exp | qual1 , … , qualn ] | ( infixexp qop ) | ( qop⟨-⟩ infixexp ) | qcon { fbind1 , … , fbindn } | aexp⟨qcon⟩ { fbind1 , … , fbindn } https://www.haskell.org/onlinereport/haskell2010/haskellch3.html were I've added (*) to where I have added or removed lines (basically I've moved function application from lexp to infixexp in order to allow the last exp in a function application to be an lexp). > At the moment the *only* robust way to pass a polymorphic function to a polymorphic function (here, you are passing Wrap to (.)) is to wrap it in a newtype, much as Wrap does. Good to know. Thanks! -Tyson

1 0

Regex-applicative and Data.Text
by Konstantine Rybnikov 11 Feb '15

11 Feb '15

I just tried some regex-applicative and it's amazing! Very nice library, thanks Roman! However, I can't figure out the best way to work with Data.Text.Text instead of String. The token would be Text, I guess, but then it breaks in composition, since type of `few anySym` would now return `[Text]`, not `Text`. Am I understanding this correctly that intention is to in issue #8? [0] Or is there a clever way to work with them today? Example code: {-# LANGUAGE OverloadedStrings #-} import qualified Data.Text as T import Data.Text (Text) import Text.Regex.Applicative main = do let input = "foo:\n--- blablabla\ttheend" let r1 = sym "foo:\n" *> sym "--- " *> few anySym <* sym "\t" <* few anySym :: RE Text Text putStrLn (show (input =~ r1)) Error is something like (this is an error for a bit different code, but should be very similar): Main.hs:14:40: Couldn't match type ‘[Text]’ with ‘Text’ Expected type: RE Text Text Actual type: RE Text [Text] In the second argument of ‘(*>)’, namely ‘few anySym’ In the first argument of ‘(<*)’, namely ‘few anySym *> sym "Actual stderr output differs from expected:" *> sym "--- " *> few anySym’ Thanks! [0]: https://github.com/feuerbach/regex-applicative/issues/8

2 2

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 11 Feb '15

11 Feb '15

4 4

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

11 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 11 Feb '15

11 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 11 Feb '15

11 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 11 Feb '15

11 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