- Haskell-Cafe - Haskell.org

`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

Cross ghc-7.8.3 for PowerPC build fails
by Jon Schneider 06 Nov '14

06 Nov '14

I got my ARM (v5) ghc cross compiler built the other day by making sure I had only the latest LLVM and Haskell Platform host packages, tweaking settings and commenting out haskeline and terminfo in the top level ghc.mk . There's something broken about terminfo but life's too short to worry about since it's not needed. The ARM cross ghc seems to product viable executables for simple code. Now a sister product is a PowerPC (MPC854E) and the ABI is gnuspe. In my PATH are (only) clangs and llcs from http://llvm.org/releases/3.4.2/clang+llvm-3.4.2-x86_64-unknown-ubuntu12.04.… and ghc from https://www.haskell.org/platform/download/2014.2.0.0/haskell-platform-2014.… Because of the none vendor I didn't seem able to put in the target I configured like this. ./configure --target=powerpc-linux-gnuspe --with-gcc=powerpc-none-linux-gnuspe-gcc --with-nm=powerpc-none-linux-gnuspe-nm --with-ld=powerpc-none-linux-gnuspe-ld --with-ar=powerpc-none-linux-gnuspe-ar --with-ranlib=powerpc-none-linux-gnuspe-ranlib This fails as follows. It seems to have generated x86 opcodes including movq unless it's something to do with GNU assembly trying to make everything have the same apparent instruction set then again %rcx and %esi are mentioned. ====== cp libffi/build/inst/lib/libffi.a rts/dist/build/libCffi_thr_l.a "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H64m -O0 -package-name ghc-prim-0.3.1.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XHaskell2010 -O -fllvm -no-user-package-db -rtsopts -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -c libraries/ghc-prim/./GHC/Types.hs -o libraries/ghc-prim/dist-install/build/GHC/Types.o /tmp/ghc30000_0/ghc30000_5.s: Assembler messages: /tmp/ghc30000_0/ghc30000_5.s:8:0: Error: Unrecognized opcode: `movl' and so on with opcodes such as jbe, leal, jmpq and also "junk at end of line: `rcx),%esi'" ====== in libffi/build/powerpc-unknown-linux-gnuspe there's a sensible config.log with x86_64 in the build variables and powerpc in the host and target ones. How do I go about making this work ? Thanks, Jon

2 4

addCatch in conduit
by Yitzchak Gale 06 Nov '14

06 Nov '14

In getting the dtd library to compile with recent versions of conduit (yes, I know that it's deprecated and Michael longer supports it, but we still need it), we came across the following bit of code: -- (snip) -- CI.ConduitM $ addCatch $ CI.unConduitM src0 where -- (snip) -- addCatch :: (MonadThrow m, MonadBaseControl IO m) => CI.Pipe l i o u m r -> CI.Pipe l i o u m r addCatch (CI.HaveOutput src close x) = CI.HaveOutput (addCatch src) (addCatch' close) x addCatch (CI.NeedInput p c) = CI.NeedInput (addCatch . p) (addCatch . c) addCatch (CI.Done r) = CI.Done r addCatch (CI.PipeM msrc) = CI.PipeM (addCatch' $ liftM addCatch msrc) addCatch (CI.Leftover p i) = CI.Leftover (addCatch p) i addCatch' m = m `Lifted.catch` throw rr We adapted it to the new ConduitM type simply by changing the first line to: CI.ConduitM $ addCatch . CI.unConduitM src0 Not bad, a diff of exactly one character. It compiles and seems to work. Does this sound reasonable? Obviously, we would love to get rid of this use of conduit internals. addCatch seems like a general operation, not specific to this library. Is there a way to do this in modern conduit without dipping into internals? If not - can we propose to add it? Thanks, Yitz

2 1

Tutorial for creating haskell apps in the browser easy
by Alberto G. Corona 05 Nov '14

05 Nov '14

Hi Just in case you don´t noticed it, this is the first tutorial for creating Browser applications in Haskell for non haskellers. http://www.airpair.com/haskell/posts/haskell-tutorial-introduction-to-web-a… -- Alberto.

2 3

installing haskell on ubuntu using apt-get??
by Vasili I. Galchin 05 Nov '14

05 Nov '14

My config: runghc 7.4.1 3.2.0-61-generic #93-Ubuntu I installed Haskell using Ubuntu's "apt-get install" ======================================================== Please see results below ... (should I instead install Haskell from haskell.org??) vasili@vasili-VirtualBox:~/biolib$ cabal configure Resolving dependencies... Configuring bio-0.5.2... Warning: This package indirectly depends on multiple versions of the same package. This is highly likely to cause a compile failure. package text-1.2.0.0 requires bytestring-0.10.4.0 package tagsoup-0.13.3 requires bytestring-0.10.4.0 package parsec-3.1.7 requires bytestring-0.10.4.0 package bio-0.5.2 requires bytestring-0.10.4.0 package binary-0.4.5 requires bytestring-0.10.4.0 package unix-2.5.1.0 requires bytestring-0.9.2.1 vasili@vasili-VirtualBox:~/biolib$

4 3