November 2014 - Haskell-Cafe

Test Framework, HUnit
by spopejoy 09 Nov '14

09 Nov '14

Hi, I started using Test Framework following the example of the lens library, specifically using Test.Framework.TH. It looks really nice, however I noticed that the TH project hasn't had any activity in 2 years ... plus the whole test framework project is very light on docs. I've been happy with straight HUnit, but I'm wanting something more structured to bring others into the project I'm working on. 1) Are there more resources on TF? 2) Is TF-TH actively maintained? Cheers, Stuart

5 5

Can I check the length in a guarded expresion
by Roelof Wobben 09 Nov '14

09 Nov '14

Hello, I try to make a guarded solution to find the last item in a list. I thought I could do something like this | length a == 1 = a But then I see a lot of error messages. Is there another way I can check the length of a list with guards ? Roelof

7 8

IO and exceptions
by Ömer Sinan Ağacan 09 Nov '14

09 Nov '14

Hi all, I'm having some trouble with IO functions and exceptions. When I call an IO function in Haskell, I feel very uncomfortable, because you never know what kind of exceptions your function may throw. There are a lot of cases where thrown exceptions are not specified in the documentation. What's worse, there are cases where it's impossible to catch thrown exceptions in a safe way. Example to not knowing what exceptions may be thrown: http://hackage.haskell.org/package/base-4.6.0.1/docs/Control-Concurrent-Cha… `readChan` blocks the thread until it reads something. But what happens when channel is closed while one thread is blocked to read? It's not mentioned in the documentation and it's not specified in terms of types. (e.g. by using Either, Maybe or similar) Example to not being able to catch the exception: http://hackage.haskell.org/package/network-2.6.0.2/docs/Network-Socket.html `recvFrom` blocks the thread until it reads something. However, what happens if socket is closed while `recvFrom` is blocking to read? Similar to `readChan`, we can't know this. What's worse is this: sockets have a `SO_RCVTIMEO` option, a timeout value for `recv_from` calls. What happens when we set that using `setSocketOption` in the same module and call `recvFrom` is unknown. This is really horrible, because a timeout exception is really something that you'd like to catch. Example: I have a thread that listens from a socket and handles some other events. I want to stop listening the socket after every second and handle events, then return listening the socket. But I can't know what it throws when timeout happens, so I have to catch all exceptions, which is horrible for a lot of reasons. I was wondering if I'm doing something wrong. I'm sure we can find a lot of cases like these and I feel like libraries are not designed very good for errors/exceptions. So I'd like to get some ideas/suggestions about this. Am I doing something wrong or did I misunderstand something? Should we improve the libraries for better types/error handling? Am I only one here that has problems with those functions? Thanks.

7 8

Extensionality principles for kinds?
by Rob 09 Nov '14

09 Nov '14

Haskellers, I've waded into some pretty deep waters, but I'm hoping there's a GHC type system wizard in here who can help me. The following code fragment is extracted from something I've been working on involving some pretty fancy type-level programming. I'm using GHC 7.8.3. I've run into a problem where the typechecker refuses to believe that two types are equal; it seems to lack the necessary extensionality principles for lifted data kinds. Basically (see below for definitions) I get into a contex where I know that (TwiceLeft a ~ TwiceLeft b) and (TwiceRight a ~ TwiceRight b), but the typechecker will not believe that (a ~ b). Are there any tricks I can employ to make this code typecheck (using only safe operations)? Bonus if it doesn't add any runtime cost. Thanks, Rob Dockins ====== code follows ====== {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE TypeFamilies #-} import Data.Type.Equality -- lifted kind (Twice k) consists of a pair of things of kind k data Twice k = TwiceVal k k -- type family accessor functions for the Twice kind type family TwiceLeft (x::Twice k) :: k where TwiceLeft (TwiceVal a b) = a type family TwiceRight (x::Twice k) :: k where TwiceRight (TwiceVal a b) = b -- Double is already taken, use Dbl instead... data Dbl (f :: k -> *) (tv :: Twice k) = Dbl (f (TwiceLeft tv)) (f (TwiceRight tv)) -- This function doesn't typecheck... doubleEq :: forall (f:: k -> *) . (forall (a::k) (b::k). f a -> f b -> Maybe (a :~: b)) -> (forall (a::Twice k) (b::Twice k). Dbl f a -> Dbl f b -> Maybe (a :~: b)) doubleEq teq (Dbl x y) (Dbl z w) = case teq x z of Nothing -> Nothing Just Refl -> case teq y w of Nothing -> Nothing Just Refl -> Just Refl

2 2

`cabal repl` problems
by Ömer Sinan Ağacan 08 Nov '14

08 Nov '14

Hi all, I have a Cabal project that has library, executable and several test parts. I'd like to be able to load one of the test parts into GHCi using `cabal repl`. However, I'm having some problems: (To be more specific, I have these parts in my Cabal file: - library - executable myapp - test-suite test - test-suite doctests) - `cabal repl test` tries to load test suite into GHCi but it doesn't ask me which test suite I want to load. For example, in my Cabal file I have `test-suite test` and `test-suite doctests`. `cabal test doctests` runs only doctests but I can't use similar command for repl, like `cabal repl doctests`. - `cabal repl test` tries to load the library, but using wrong set of dependencies. It uses `build-depends` field of `test-suite test` but it loads `library` sources. Note that `hs-source-dirs` field of `test-suite test` and `library` are different, and I have my library in `test-suite test` as a dependency. So the problem is that it tries to load `library` part using the source, instead of compiled lib. Any ideas about those? (Note: `cabal test`, `cabal install`, `cabal run` etc. work fine, my Cabal file is working) Thanks.

2 2

why is haddock so slow
by Johannes Waldmann 07 Nov '14

07 Nov '14

I have a larg-ish project (800 modules) and these ghc compilation times: cabal install : 19 min cabal install --disable-doc : 13 min the compilation includes the profiling build. That is, running haddock takes the same 6 minutes as running the compiler (with optimization) I also built with "optimization: False library-profiling: False" and this takes 3 min. I understand that haddockification goes via the compiler's front-end to resolve names and infer types. This takes 3 min (as the non-optimizing compiler run shows). What does haddock do in the other 3 min? What could I do to help analyze this? - J.W. (ghc-7.8.3, haddock 2.15.0, rotating disk (not SSD), Fedora 20, x86_64)

2 4

Travis builds failing with spurious errors
by Francesco Mazzoli 07 Nov '14

07 Nov '14

Hi all, Apologies if this is not the right space to ask this question. We set up CI for Agda with Travis: <https://travis-ci.org/agda/agda>. The problem is that we're having trouble with older versions of GHC. For example, with GHC 7.4.2, the build complains that ScopedTypeVariables is not enabled, even if it is. You can check the build failure here: <https://travis-ci.org/agda/agda/jobs/39834738#L795>, and the relevant file here: <https://github.com/agda/agda/blob/9a82afaf7657a97e85e7e31ea23f6386f99acd35/…>. As you can see from the pragmas ScopedTypeVariables is enabled, and in fact when building locally I have no problems. We also got some spurious messages regarding syntax. Has anybody encountered similar problems? I don't know if it's something depending on Travis or some configuration mistakes, but I'm a bit at loss on how to research this. Moving the OPTIONS_GHC pragma after the LANGUAGE pragmas seems to fix the issue but I'd like to know what's going on. Thanks, Francesco

2 1

Fwd: Increasing Haskell modularity
by Gesh hseG 07 Nov '14

07 Nov '14

Sorry, should have used reply-list. To clarify, under the proposal, the associated family instances would also be locally unique, with local instances overriding global instances. Gesh ---------- Forwarded message ---------- From: Gesh <gesh(a)gesh.uni.cx> Date: Wed, Oct 1, 2014 at 5:30 PM Subject: Re: [Haskell-cafe] Increasing Haskell modularity To: Richard Eisenberg <eir(a)cis.upenn.edu> On 10/1/2014 5:01 PM, Richard Eisenberg wrote: > > * I'm not sure exactly what you mean by "adopt [Oleg's] proposal". In Section 6.1, Oleg discusses how to keep principal typing while allowing local instances. He then suggests making this part of the semantics of local instances. > It seems the first part of your proposal just says > "Haskellers can no longer expect class instance coherence." > As such, this is a drastic change that would require all Haskell > programs to be inspected to see if they crucially rely on coherence No. Coherence is preserved, since you always use the unique in-scope dictionary. What *is* lost, however, is global uniqueness, which means that code that assumes that the same dictionary is used for the same type across calls to functions must be modified. Arguably, that code is semantically incorrect to begin with, but that's neither here nor there. > * As for associated vs. non-associated type families: > There is essentially no difference between associated > and non-associated type families, save concrete syntax. > If the Haskell house were on fire and we needed to eliminate > one of these forms, I would agree to it without much trouble, > because the two forms are equally expressive. > > > But, eliminating non-associated type families wouldn't solve > your problem at all: while class instance incoherence causes > wonky runtime behavior, associated type instance incoherence > breaks the type system. If I understand your proposal correctly, > users could implement unsafeCoerce through clever hackery around > associated type instance incoherence. This seems to be against > the Haskell tradition of strong typing. To clarify my proposal: Associated type families have the added guarantee over non-associated families that functions will be defined that allow one to work with them. As mentioned above, typeclass coherence is preserved under the proposal, so I see no danger of family incoherence. However, I'm inexperienced with these kinds of proposals, and the concern that unsafeCoerce will be possible with this proposal is worrying. Could you please construct a case implementing unsafeCoerce? Thanks, Gesh

15 26

ICFP 2015: Call for Papers
by David Van Horn 07 Nov '14

07 Nov '14

===================================================================== 20th ACM SIGPLAN International Conference on Functional Programming ICFP 2015 Vancouver, Canada, August 31 - September 2, 2015 http://www.icfpconference.org/icfp2015 ===================================================================== Important Dates ~~~~~~~~~~~~~~~ Submissions due: Friday, February 27 2015, 23:59 UTC-11 Author response: Tuesday, April 21, 2015 through Thursday, 23 April, 2015 Notification: Friday, May 1, 2015 Final copy due: Friday, June 12, 2015 Scope ~~~~~ ICFP 2015 seeks original papers on the art and science of functional programming. Submissions are invited on all topics from principles to practice, from foundations to features, and from abstraction to application. The scope includes all languages that encourage functional programming, including both purely applicative and imperative languages, as well as languages with objects, concurrency, or parallelism. Topics of interest include (but are not limited to): * Language Design: concurrency, parallelism, and distribution; modules; components and composition; metaprogramming; type systems; interoperability; domain-specific languages; and relations to imperative, object-oriented, or logic programming. * Implementation: abstract machines; virtual machines; interpretation; compilation; compile-time and run-time optimization; garbage collection and memory management; multi-threading; exploiting parallel hardware; interfaces to foreign functions, services, components, or low-level machine resources. * Software-Development Techniques: algorithms and data structures; design patterns; specification; verification; validation; proof assistants; debugging; testing; tracing; profiling. * Foundations: formal semantics; lambda calculus; rewriting; type theory; monads; continuations; control; state; effects; program verification; dependent types. * Analysis and Transformation: control-flow; data-flow; abstract interpretation; partial evaluation; program calculation. * Applications: symbolic computing; formal-methods tools; artificial intelligence; systems programming; distributed-systems and web programming; hardware design; databases; XML processing; scientific and numerical computing; graphical user interfaces; multimedia and 3D graphics programming; scripting; system administration; security. * Education: teaching introductory programming; parallel programming; mathematical proof; algebra. * Functional Pearls: elegant, instructive, and fun essays on functional programming. * Experience Reports: short papers that provide evidence that functional programming really works or describe obstacles that have kept it from working. If you are concerned about the appropriateness of some topic, do not hesitate to contact the program chair. Abbreviated instructions for authors ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * By Friday, 27 February 2015, 23:59 UTC-11 (anywhere in the world), submit a full paper of at most 12 pages (6 pages for an Experience Report) in standard ACM conference format, including bibliography, figures, and appendices. The deadlines will be strictly enforced and papers exceeding the page limits will be summarily rejected. * Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. * Each submission must adhere to SIGPLAN's republication policy, as explained on the web at http://www.sigplan.org/Resources/Policies/Republication * Authors of resubmitted (but previously rejected) papers have the option to attach an annotated copy of the reviews of their previous submission(s), explaining how they have addressed these previous reviews in the present submission. If a reviewer identifies him/herself as a reviewer of this previous submission and wishes to see how his/her comments have been addressed, the program chair will communicate to this reviewer the annotated copy of his/her previous review. Otherwise, no reviewer will read the annotated copies of the previous reviews. Overall, a submission will be evaluated according to its relevance, correctness, significance, originality, and clarity. It should explain its contributions in both general and technical terms, clearly identifying what has been accomplished, explaining why it is significant, and comparing it with previous work. The technical content should be accessible to a broad audience. Functional Pearls and Experience Reports are separate categories of papers that need not report original research results and must be marked as such at the time of submission. Detailed guidelines on both categories are on the conference web site. Proceedings will be published by ACM Press. Authors of accepted submissions will have a choice of one of three ways to manage their publication rights. These choices are described at http://authors.acm.org/main.html Presentations will be videotaped and released online if the presenter consents. The proceedings will be freely available for download from the ACM Digital Library from one week before the start of the conference until two weeks after the conference. Formatting: Submissions must be in PDF format printable in black and white on US Letter sized paper and interpretable by Ghostscript. Papers must adhere to the standard ACM conference format: two columns, nine-point font on a ten-point baseline, with columns 20pc (3.33in) wide and 54pc (9in) tall, with a column gutter of 2pc (0.33in). A suitable document template for LaTeX is available at http://www.acm.org/sigs/sigplan/authorInformation.htm Submission: Submissions will be accepted on the web using a link that will be posted at http://icfpconference.org/icfp2015/ Improved versions of a paper may be submitted at any point before the submission deadline using the same web interface. Author response: Authors will have a 72-hour period, starting at 0:00 UTC on Tuesday, 21 April 2015, to read reviews and respond to them. ACM Author-Izer is a unique service that enables ACM authors to generate and post links on either their home page or institutional repository for visitors to download the definitive version of their articles from the ACM Digital Library at no charge. Downloads through Author-Izer links are captured in official ACM statistics, improving the accuracy of usage and impact measurements. Consistently linking the definitive version of ACM article should reduce user confusion over article versioning. After your article has been published and assigned to your ACM Author Profile page, please visit http://www.acm.org/publications/acm-author-izer-service to learn how to create your links for free downloads from the ACM DL. Publication date: The official publication date of accepted papers is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. General Chair: Kathleen Fisher Tufts University (USA) Program Chair: John Reppy University of Chicago (USA) Program Committee: Amal Ahmed Northeastern University (USA) Jean-Philippe Bernardy Chalmers University of Technology (Sweden) Matthias Blume Google (USA) William Byrd University of Utah (USA) Andy Gill University of Kansas (USA) Neal Glew Google (USA) Fritz Henglein University of Copenhagen (Denmark) Gabriele Keller University of New South Wales and NICTA (Australia) Andrew Kennedy Microsoft Research Cambridge (UK) Neelakantan Krishnaswami Birmingham University (UK) Daan Leijen Microsoft Research Redmond (USA) Keiko Nakata Institute of Cybernetics at Tallinn University of Technology (Estonia) Mike Rainey INRIA Rocquencourt (France) Andreas Rossberg Google (Germany) Manuel Serrano INRIA Sophia Antipolis (France) Simon Thompson University of Kent (UK) David Van Horn University of Maryland (USA) Stephanie Weirich University of Pennsylvania (USA)

1 0

Haskell.org access problems
by Henk-Jan van Tuyl 07 Nov '14

07 Nov '14

L.S., When I try to browse haskell.org with Opera, I get the following message: --- Unable to complete secure transaction You tried to access the address http://www.haskell.org/, which is currently unavailable. Please make sure that the web address (URL) is correctly spelled and punctuated, then try reloading the page. Secure connection: fatal error (1066) https://www.haskell.org/ Unable to verify the website's identity (OCSP error). The response from the online certificate validation (OCSP) server was too old. --- The browser doesn't allow me in. Another thing that I get with Firefox: a captcha, probably because I am using the TOR network and the site is buffered by CloudFlare. Opera does not handle these captchas properly. Regards, Henk-Jan van Tuyl -- Folding@home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming --

1 0