October 2017 - Haskell-Cafe

Fwd: Safe TCP accept loop
by Sumit Raja 30 May '18

30 May '18

Hi, I sent this to beginners but got no responses so I'm hoping someone here can help. I’ve looked at https://wiki.haskell.org/Concurrency_demos/Graceful_exit and used(2) Using throwTo without the use of block and unblock. It runs on 8.2.1 with my limited testing. I can’t find out much about what the > 7.x GHC replacement for block/unblock is other than mask. What does the unblock do in acceptConnections'? Does this method of handling an accept loop still need masking of async exceptions ? If so where does this need to be done? I've got a version with async running for my specific application (https://bitbucket.org/sumitraja/hvrr/src/6927216597a35a9a0d7f2e55cca83fa5b7…) but I don't know if I need to unmask at any point so was hoping for some guidance. Thanks Sumit

2 4

Archival of community.haskell.org
by Mario Rogic 19 May '18

19 May '18

Hi all As announced back in 2015 <http://blog.haskell.org/post/7/the_future_of_community.haskell.org/> we have started archiving community.haskell.org services. We've created https://archives.haskell.org/, and the old projects mailing lists have been the first to be archived. Next on the list is the remainder of projects.haskell.org, and the code.haskell.org site. As always, you can email admin(a)h.o or hop on the #haskell-infrastructure freenode channel to provide feedback / concerns. Thanks - Mario

1 2

Join a transformer
by Michael Snoyman 11 Apr '18

11 Apr '18

I'm wondering if this pattern exists and has a name. We have the concept of joining a Monad: join :: Monad m => m (m a) -> ma How about joining a monad transformer? joinT :: (Monad m, MonadTrans t) => t (t m) a -> t m a I believe implementing this in terms of MonadTransControl[1] might be possible, but I was wondering if there's an already existing idiom for this. Michael [1] http://haddocks.fpcomplete.com/fp/7.4.2/20130301-40/monad-control/Control-M…

5 5

PatternSignatures (rant)
by Johannes Waldmann 06 Apr '18

06 Apr '18

Dear all, (this is a rant - please ignore) why has "PatternSignatures" been renamed to "ScopedTypeVariables" (in ghc-6.10)? show me the alleged "type variable" in this code: do x :: Int <- [ 1 .. 10 ] ; return $ x^2 and why on earth do I need to use a language extension at all to get to the most basic thing of declarative programming: to declare the type of an identifier? This seriously hurts (me, at least) when teaching Haskell. Thanks - J.W.

4 4

ANN: nice-html, an all-around "nice" html templating library, similar but different to lucid, blaze, type-of-html, etc.
by Mike Ledger 08 Nov '17

08 Nov '17

Hi Haskell-Cafe, I've been working on and off on a HTML templating library that is slightly novel for a few months. Here's the good parts: * it's faster than lucid and blaze * it has a valid monad instance * it has another valid monad instance, that is slightly different! * it paramaterises templates by the data they require * the HTML5 combinators don't rely on any highly overloaded/overlapping typeclasses; type errors in nice-html templates tend to be nice monomorphic type mismatches To achieve this, it has a distinct compilation phase (at runtime) for templates. This means the actual rendering function does very little beyond concatenate Text and escape dynamic input. It also severely restricts usage to the built-in combinators available -- at least, for dynamic data -- and can make writing a nice-html template difficult, though littering _ throughout type signatures helps. Check it out! Benchmark results, a README, and an example: https://github.com/TransportEngineering/nice-html Hackage: https://hackage.haskell.org/package/nice-html The only thing on the roadmap right now is to have some nice :-) way to assign JavaScript event handlers to Markup. This is something that I really appreciate when using React.js, so my eventual aim is for nice-html to be like a (more) server-side version of React. Right now, you can keep track of element ids with `Text.Html.Writer.note`, but it's neither a very good nor very useful interface. Cheers, Mike

3 5

[ANNOUNCE] GHC 8.2.2 release candidate 2
by Ben Gamari 06 Nov '17

06 Nov '17

Hello everyone, The GHC team is very pleased to announce the second candidate of the 8.2.2 release of the Glasgow Haskell Compiler. Source and binary distributions are available at https://downloads.haskell.org/~ghc/8.2.2-rc2/ This is the second and hopefully last of two release candidates leading up the final 8.2.2 release. This release fixes approximately fifty bugs present in 8.2.1. These most notably include, * A correctness issue resulting in segmentation faults in some FFI-users (#13707, #14346) * A correctness issue resulting in undefined behavior in some programs using STM (#14171) * A bug which may have manifested in segmentation faults in out-of-memory condition (#14329) * clearBit of Natural no longer bottoms (#13203) * A specialisation bug resulting in exponential blowup of compilation time in some specialisation-intensive programs (#14379) * ghc-pkg now works even in environments with misconfigured NFS mounts (#13945) * GHC again supports production of position-independent executables (#13702) * Better error messages around kind mismatches (#11198, #12373, #13530, #13610) See [1] for the full list. As always, please report any issues you encounter. Happy testing, - Ben [1] https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.2.2&col=id…

7 10

[ANNOUNCE] GHC 8.2.2 release candidate 3
by Ben Gamari 31 Oct '17

31 Oct '17

Hello everyone, The GHC team is very pleased to announce the third candidate of the 8.2.2 release of the Glasgow Haskell Compiler. Source and binary distributions are available at https://downloads.haskell.org/~ghc/8.2.2-rc3/ This is the third and last of three release candidates leading up the final 8.2.2 release. This release fixes approximately fifty bugs present in 8.2.1. These most notably include, * A correctness issue resulting in segmentation faults in some FFI-users (#13707, #14346) * A correctness issue resulting in undefined behavior in some programs using STM (#14171) * A bug which may have manifested in segmentation faults in out-of-memory condition (#14329) * clearBit of Natural no longer bottoms (#13203) * A specialisation bug resulting in exponential blowup of compilation time in some specialisation-intensive programs (#14379) * ghc-pkg now works even in environments with misconfigured NFS mounts (#13945) * GHC again supports production of position-independent executables (#13702) * Better error messages around kind mismatches (#11198, #12373, #13530, #13610) See [1] for the full list. Release candidate three contains only two patches not present in -rc2 but fixes a packaging issue which lead to unintentional downgrading the process and Cabal libraries. As always, please report any issues you encounter. Happy testing, - Ben [1] https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.2.2&col=id…

1 0

What Does Graham Hutton Mean by Effect
by Steven Leiva 31 Oct '17

31 Oct '17

Hi Everyone, I am reading the 2nd edition of Graham Hutton's Programming in Haskell. I'm not reading the entire book, just the parts of Haskell that I am still iffy on. Anyway, in Chapter 12, Section 3, Hutton introduces monads. He start off with the following code: first module Expr wheredata Expr = Val Int | Div Expr Expreval :: Expr -> Inteval (Val n) = neval (Div el er) = eval el `div` eval er Not using Mixmax yet? And then he points out that the second clause of eval will raise an error if eval er evaluates to 0. One solution is that, instead of using the div function, we use a safeDiv:: Int -> Int -> Maybe Int function, which evaluate to Nothing if the divisor is 0. This means that expr's type changes from eval :: Eval -> Int to eval :: Eval -> Maybe Int, and this means that implementing eval becomes very verbose: second module Expr wheredata Expr = Val Int | Div Expr Expreval :: Expr -> Maybe Inteval (Val n) = Just neval (Div el er) = case eval el of Nothing -> Nothing Just y -> case eval er of Nothing -> Nothing Just x -> y `safeDiv` xsafeDiv :: Int -> Int -> Maybe IntsafeDiv x y | y == 0 = Nothing | otherwise = Just (x `div` y) Not using Mixmax yet? In order to make eval more concise, we can try the applicative style, where the second clause of the eval function becomes pure safeDiv <*> eval el <*> eval er. Of course, that doesn't work because pure safeDiv has the type Int -> Int -> Maybe Int, and what we need is a function of type Int -> Int -> Int. Anyways, this is all setup / context to what Hutton says next: The conclusion is that the function eval does not fit the pattern of effectful programming that is capture by applicative functors. The applicative style restricts us to applying pure functions to effectful arguments: eval does not fit this pattern because the function safeDiv that is used to process the resulting values is not a pure function, but may itself fail. I am confused by Hutton's use of the word effectful and by his description of safeDiv as "not a pure function". I tried skimming the other sections of the book to see if he provided a definition of this somewhere, but if he did, I couldn't find it. So my question is, in what way does Hutton mean for the reader to understand the words effect / effectful, and why does he describe the function safeDiv as not a pure function? Thank you! Steven Leiva 305.528.6038 leiva.steven(a)gmail.com http://www.linkedin.com/in/stevenleiva

3 5

Call for Sponsorships: ICFP 2018
by Lindsey Kuper 30 Oct '17

30 Oct '17

ICFP 2018 The 23rd ACM SIGPLAN International Conference on Functional Programming https://icfp18.sigplan.org Call for Sponsorships Web version of this call for sponsorships: https://icfp18.sigplan.org/attending/supporting-icfp ## Why Sponsor ICFP 2018? ICFP is the premier conference on functional programming languages, covering all aspects of theory, implementation, and application. Every year, we bring together over 500 world-leading researchers, practitioners, and students to discuss the latest findings, collaborate on new ideas, and meet new people. By sponsoring ICFP, your organization can demonstrate its commitment to supporting high quality research and to developing the next generation of functional programming experts. Most of our sponsorship funds are used to help students from around the world afford to attend the conference and get the most out of their experience. We believe that this commitment will pay dividends for our students, our sponsors, and the public for years to come. If you're interested in becoming a sponsor, we'd love to hear from you: get in touch with our sponsorship team at sponsorship-2018(a)icfpconference.org ## Sponsorship Opportunities and Benefits ### Bronze - $750 * Your logo on the ICFP 2018 website * Your name listed in the proceedings ### Silver - $3,000 * All of the benefits of Bronze sponsorship * One complimentary 3-day ICFP registration * A table at the industrial reception * Your logo in the proceedings * Your logo on publicity materials such as banners and posters ### Gold - $6,000 * All of the benefits of Silver sponsorship * One additional complimentary 3-day ICFP registration (2 in total) * A named supporter of the industrial reception * An opportunity to include branded merchandise in participants' swag bag ### Platinum - $10,000 * All the benefits of Gold sponsorship * One additional complimentary 3-day ICFP registration (3 in total) * A named supporter of ICFP 2018 * An opportunity to speak to the audience at the industrial reception * A table/booth-like space in the coffee break areas ## Additional Sponsorship Opportunities We offer some additional sponsorship options to sponsors at the silver level or above. ### Lanyard Sponsor - $4,000 You provide the lanyards that every attendee will wear around their neck. ### Video Sponsor - $4,000 ICFP makes videos available for free to non-attendees following the conference. As a video sponsor, you support the recording and release of these videos. In exchange, your logo will be displayed as part of every ICFP video. ### Banner - $1,000 Post a free-standing banner (up to 2m high and 1m wide, provided by you) on the ICFP main stage throughout the conference.

1 0

newtype and access control
by Steven Leiva 29 Oct '17

29 Oct '17

Hello everyone, I am watching a talk on YouTube calledWrangling Monad Transformer Stacks. The talk has the following code: code{-# LANGUAGE GeneralizedNewtypeDeriving -#} module DBTrans where newtype WithTrans a = WithTrans (WithDBConn a) deriving (Functor, Applicative, Monad) inDBTrans :: WithTrans a -> WithConn a inDBTrans = ... NOT USING MIXMAX YET? The speaker mentions that by using a newtype, we can perform "access control". The functioninDBTrans is "aware" that the type constructorWithTrans is simply a wrapper forWithDBConn, and that functions outside of the module are not privy to that information. Out of necessity, the speaker has to assume a certain level of Haskell knowledge that I don't have, because I am confused as to what language principles would allow forinDBTrans to be used for access control. I understand that a newtype declaration does create a new type from a "type safey" point of view; that a newtype declaration is required to have a single data constructor with a single (not named) field; and that, once the type-checking is done, the compiler can strip out the newtype wrapper and leave the underlying type (informally speaking, of course), but that still doesn't get me toinDBTrans can do access control. Thank you for any help! Steven Leiva 305.528.6038 leiva.steven(a)gmail.com http://www.linkedin.com/in/stevenleiva

2 2