- Haskell-Cafe - Haskell.org

Fwd: WSJ.com - Coding isn't just for those IT guys anymore
by Vasili I. Galchin 14 Mar '14

14 Mar '14

I wish Haskell could get this kind of media coverage .... ;<) Vasili ---------- Forwarded message ---------- From: vigalchin(a)gmail.com <vigalchin(a)gmail.com> Date: Thu, Mar 13, 2014 at 8:48 PM Subject: WSJ.com - Coding isn't just for those IT guys anymore To: vigalchin(a)gmail.com Cc: vigalchin(a)gmail.com [image: The Wall Street Journal] <http://www.wsj.com> * Please note, the sender's email address has not been verified You have received the following link from *vigalchin@gmail.com*<vigalchin(a)gmail.com> :. WSJ.com - Coding isn't just for those IT guys anymore<http://online.wsj.com/news/article_email/SB30001424052702304709904579411354…> Subscriber-only content will be available to non-subscribers for up to seven days after it is emailed. This article can also be accessed if you copy and paste the entire address below into your web browser. http://online.wsj.com/news/article_email/SB30001424052702304709904579411354…

3 2

Track Exceptions
by Silvio Frischknecht 13 Mar '14

13 Mar '14

Hi everyone, It's always very annoying not knowing what could go wrong (what exceptions might be thrown) when calling a library function. In java doc, for instance, you can usually see what exceptions can be thrown by a specific function. I was wondering if this could be achieved for haskell by tracing "throw" and "catch" calls. Silvio

7 7

Haskell Symposium 2014: Call for papers
by Wouter Swierstra 13 Mar '14

13 Mar '14

=================================================================== ACM SIGPLAN HASKELL SYMPOSIUM 2014 CALL FOR SUBMISSIONS Gothenburg, Sweden, 4-5 September 2014, directly after ICFP http://www.haskell.org/haskell-symposium/2014 haskell2014(a)easychair.org =================================================================== The ACM SIGPLAN Haskell Symposium 2014 will be colocated with the 2014 International Conference on Functional Programming (ICFP) in Gothenburg, Sweden. Like last year, the symposium will last 2 days. Thanks to broader participation from a growing community, we will be able to include more regular papers as well as system demonstrations, while upholding the scientific quality of the symposium. The Haskell Symposium seeks to present original research on Haskell, to discuss practical experience and future development of the language, as well as to promote other forms of denotative programming. Topics of interest include * Language Design, with a focus on possible extensions and modifications of Haskell as well as critical discussions of the status quo; * Theory, such as formal semantics of the present language or future extensions, type systems, effects, metatheory, and foundations for program analysis and transformation; * Implementations, including program analysis and transformation, static and dynamic compilation for sequential, parallel, and distributed architectures, memory management, as well as foreign function and component interfaces; * Tools, such as profilers, tracers, debuggers, preprocessors, and testing tools; * Applications, to scientific and symbolic computing, databases, multimedia, telecommunication, the web, and so forth; * Functional Pearls, being elegant and instructive programming examples; * Experience Reports, to document general practice and experience in education, industry, or other contexts. Such reports are shorter than regular papers; they are limited to six pages. Papers in the latter two categories need not necessarily report original research results. They may report instead, for example, reusable programming idioms, elegant ways to approach a problem, or practical experience that will be useful to other users, implementors, or researchers. The key criterion for such a paper is that it makes a contribution from which other Haskellers can benefit. It is not enough simply to describe a program! Regular papers should explain their research contributions in both general and technical terms, identifying what has been accomplished, explaining why it is significant, and relating it to previous work (also for other languages where appropriate). In addition, we solicit proposals for * System Demonstrations (no longer than a regular paper talk), based on running (perhaps prototype) software rather than necessarily on novel research results. These proposals should summarize the system capabilities that would be demonstrated. The proposals should explain (and will be judged on) whether the ensuing session is likely to be important and interesting to the Haskell community at large, whether on grounds academic or industrial, theoretical or practical, technical or social. Please contact the program chair with any questions about the relevance of a proposal. Travel Support: =============== Student attendees with accepted papers can apply for a SIGPLAN PAC grant to help cover travel expenses. PAC also offers other support, such as for child-care expenses during the meeting or for travel costs for companions of SIGPLAN members with physical disabilities, as well as for travel from locations outside of North America and Europe. For details on the PAC programme, see its web page (http://www.sigplan.org/PAC.htm) Proceedings: ============ ACM Press will publish formal proceedings. Accepted papers will be included in the ACM Digital Library. Authors must grant ACM publication rights upon acceptance (http://authors.acm.org/main.html) but may retain copyright if they wish. Authors are encouraged to publish auxiliary material with their paper (source code, test data, and so forth). 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. Accepted proposals for system demonstrations will be posted on the symposium web page, but not formally published in the proceedings. Submission Details: =================== Submitted papers should be in portable document format (PDF), formatted using the ACM SIGPLAN style guidelines (http://www.acm.org/sigs/sigplan/authorInformation.htm) The text should be in a 9-point font in two columns. The length is restricted to 12 pages, except for "Experience Report" papers, which are restricted to 6 pages. Papers need not fill the page limit. Each paper submission must adhere to SIGPLAN's republication policy, as explained on the web. Proposals for system demonstrations are limited to 2-page abstracts, in the same ACM format as papers. "Functional Pearls", "Experience Reports", and "Demo Proposals" should be marked as such with those words in the title at time of submission. The paper submission deadline and length limitations are firm. There will be no extensions, and papers violating the length limitations will be summarily rejected. Submission is via EasyChair: https://www.easychair.org/conferences/?conf=haskell14 * Abstract submission: Fri 09 May 2014 * Paper submission : Mon 12 May 2014 * Demo submission : Fri 30 May 2014 (prior abstract submission unnecessary) * Author notification: Wed 11 June 2014 * Final papers due : Sun 22 June 2014 All deadlines, except the final papers deadline, are in Standard Samoan Time. Programme Committee: ==================== George Giorgidze - Standard Chartered Bank Mauro Jaskelioff - Universidad Nacional de Rosario Mark Jones - Portland State University Lindsey Kuper - Indiana University José Pedro Magalhães - University of Oxford Geoffrey Mainland - Drexel University Simon Marlow - Facebook Shin Cheng Mu - Academia Sinica Keiko Nakata - Institute of Cybernetics, Tallinn University of Technology Bruno Oliveira - University of Hong Kong Lee Pike - Galois Josef Svenningsson - Chalmers University of Technology Wouter Swierstra - University of Utrecht (chair) Simon Thompson - University of Kent

1 0

pure ghc
by joakim＠comex.se 12 Mar '14

12 Mar '14

Hello, If I compile my source code two time I would like to get the same binary. But currently when I run echo "main = return ()" > c.hs && ghc -fforce-recomp c.hs && xxd c > c1.hex && ghc -fforce-recomp c.hs && xxd c > c2.hex && diff c1.hex c2.hex my output is [1 of 1] Compiling Main ( c.hs, c.o ) Linking c ... [1 of 1] Compiling Main ( c.hs, c.o ) Linking c ... 55494c55494 < 00d8c50: 7400 6768 6333 3130 3830 5f30 2e63 0073 t.ghc31080_0.c.s --- > 00d8c50: 7400 6768 6333 3130 3935 5f30 2e63 0073 t.ghc31095_0.c.s So why does the binary differ? Is there a way to compile with ghc and get the same binary? Even though only one byte differ, the checksum (sha,md5,..) is completely changed... I'm running Linux and ghc 7.6.3. Regards, Joakim

4 4

ANN: generic-church-0.1.0.1
by Danny Gratzer 12 Mar '14

12 Mar '14

Hi cafe! I'm happy to announce the first release of generic-church<http://hackage.haskell.org/package/generic-church-0.1.0.1>. A small library for converting types equipped with a [GHC.Generic] instance back and forth between their church representations automatically. For example > let x :: a -> (Int -> a) -> a; x = toChurch $ Just 1 > x False (const True) True And we can go the other way with [fromChurch] > fromChurch (\_ f -> f 1) :: Maybe Int 1 If you're interested in the typeclass/family hacking behind the scenes, I've blogged a <http://jozefg.bitbucket.org/posts/2014-03-06-church.html> few <http://jozefg.bitbucket.org/posts/2014-03-07-church-the-sequel.html> times<http://jozefg.bitbucket.org/posts/2014-03-10-revenge-of-churchrep.html>about it. Cheers, Danny Gratzer

1 0

Read instance for constructors?
by Semen Trygubenko / Семен Тригубен ко 12 Mar '14

12 Mar '14

Dear Haskell-cafe, When deriving (Read), only values can be read in. If one wants to be able to read in constructors, too, is there an easy way out? E.g., the code below works, but the extra book-keeping f "A" = A ... is unpleasant — perhaps there's a simpler solution? {-# LANGUAGE FlexibleInstances #-} data D = A Int | B Int deriving (Show,Read) instance Read (Int -> D) where readsPrec = \_ s -> [(f s,"")] where f "A" = A f "B" = B f x = error $ "Invalid constructor " ++ x main = do let x = read "A 1" :: D print x let g s = read s :: (Int -> D) print $ g "B" 2 print $ g "C" 3 Many thanks in advance, Semen -- Семен Тригубенко http://trygub.com

4 10

ANN: engineering-units-0.0.1
by Tom Hawkins 11 Mar '14

11 Mar '14

Hi, I just uploaded a handy library for managing engineering units. It provides a Num type that allows you to mix units into calculations. It also converts between units automatically and will error out if you try to mix values with inconsistent units. Here's an example that computes the horsepower of a hydraulic pump (power = pressure * flow): flow = 20 * gpm -- Gallons per minute. pressure = 3000 * psi -- Pounds per square inch. power = pressure * flow powerHP = value power hp -- Get the value in horsepower. powerKW = value power kw -- Get the value in Kilowatts. If you don't see your units in the library, it's easy to add new ones: mm :: Value mm = 0.001 * m Wish I had this back in college. -Tom http://hackage.haskell.org/package/engineering-units

6 5

Library for service(windows) / daemon(linux)
by Miro Karpis 11 Mar '14

11 Mar '14

Hi Cafe, I need to write a service that should run on windows and on linux (after recompilation of course). One option is to use Qt Service Framework, but I was hoping that I could use Haskell for this task. Unfortunately I can not find anything similar. Please does anybody know about a library that could fulfil more or less the requirement? Cheers, Miro

2 1

On Haskell IDEs
by Niklas Hambüchen 11 Mar '14

11 Mar '14

On 10/03/14 16:22, Michal Antkiewicz wrote:> > > I would say making ghci a full-blown IDE backend akin lisps > slime-swank or clojure nrepl would be the best approach. > > there's already hdevtools which plays that role - it provides all sorts > of information to an IDE, like types, location of declarations, etc. > It's a background process and it's quite responsive (tries to be > incremental). I don't know how it is implemented and whether it is a > wrapper around GHCi. > > But I agree that all IDEs should simply use GHCi as the official IDE > backend. Maybe some parts from scion/hdevtools/ghc-mod/etc. could be > pulled back into GHCi? > > Michal Mateusz just clarified that his proposal is more about improving Yi as an editor than making it more of a Haskell IDE, so I am replying to this in a new thread. Alexandr Ruchkin and me maintain SublimeHaskell, the most-used Haskell plugin for Sublime Text. It integrates ghc-mod, hdevtools, cabal etc. and can do things like showing compile errors, completing imports, displaying the type of an expression in the buffer or insert it over a function declaration. When we want to change a Haskell file's content, we get the relevant info from, say, ghc-mod and then do the actual modification logic in the editor scripting language (in our case Python). We recognise that this logic is duplicated in pretty much every editor with such Haskell features, and at the same think that Haskell is a much nicer language to program this logic. Technically, it is also less error prone to work with ghc-mod's API than with its command line interface. That's why we seem to move more and more to do the actual modifications in an external Haskell program, and have the part in the actual editor be as minimal as possible. Alexandr started a project called "hsdev" (https://github.com/mvoidex/hsdev) for that. It is very editor-agnostic and we think that sharing something like that across editors makes sense since it could save plugin writers a lot of time. The ideas is that you would tell this tool to perform an action, e.g. "import missing imports" or "go to declaration", and it would do it for you instead implementing the buffer changes in your editor plugin. There is one problem with that: Editors don't deal well with other programs editing currently opened files. In Sublime's case, the buffer will automatically refresh, but it is very well possible that your caret position and undo history get lost, which totally interrupts the work flow. So I was wondering what the most minimal interface would be that allows your editor to be aware of the changes that an external program (HaRE, hsdev, etc.) would like to make to your code base. At the moment we consider having hsdev outputting a diff format that describes the changes, and then each editor would have to implement a simple interpreter that goes through the files, applying the changes. That way we can avoid an external file change and the problems that come with it. The Sublime-related discussion about this is at https://github.com/SublimeHaskell/SublimeHaskell/pull/132#issuecomment-3388…. I think that IDE-style "smart language features" might have a better place in cross-editor tools than in the editors themselves. ghc-mod is a successful example. I also think that most Haskell-IDE maintainers would agree (please correct me otherwise) that doing program transformation features is much more pleasant to do in Haskell than in Elisp, Vimscript, Python or Java, and that specifying out a cross-editor "modification description" and implementing the smart parts in a shareable tool might save us all a lot of time. It looks like Scion (http://code.google.com/p/scion-lib/) followed similar goals, but doesn't seem to have found wide adoption and no real development for multiple years. I would welcome a discussion about why past attempts to this failed, whether you think that having a monolithic Haskell-IDE-tool output diffs for any editor to apply would lower the barriers for making editors Haskell-smart, and if you are an editor plugin maintainer, if you agree that sharing common functionality is worth it.

12 18

GSOC Project Ideas
by Allan Gardner 11 Mar '14

11 Mar '14

I went through the GSOC trac, most of the Haskell IRC logs, and the Haskell idea reddit. So now I have a list of ideas (grouped by category): infrastructure: - C++ integration (e.g. finish https://github.com/ofan/hqt https://github.com/ofan/fficxx ) - Ada/Python/... integration - gobject bindings (gtk2hs stuff) - cabal improvements - Haddock flags ( https://github.com/haskell/cabal/issues/1585) custom setup improvements (https://github.com/haskell/cabal/issues/948) some sort of plugin system for tests/docs/other random things (BNFC), clean up and merge parallel build code, package management, ... - Hackage2 improvements - voting, rewrite auth system, speed up reverse-deps enough to enable on main site, package wiki/comments, deprecations w/ links, create haddock even if the package doesn't build, ... - scale up Hoogle so it can search all of hackage by default - scoutess work (integration with with hackage, ghc snapshots, ...) libraries: - email/PIM library (MIME, imap, ical, XMPP, WebDav, ... probably make use of a lot of old HaskellNet code) - comprehensive Date/Time API - there are lots of Hackage libs, but none do e.g. internationalization - aim to be backwards-compatible with time - highlight code using inferred types - HsColour + haskell-src/type-exts ? (maybe not enough for a GSOC?) - implement miscellaneous concurrent data structures - darcs improvements (performance, storage, ...) - fix pandoc conversion issues - ... (there were a lot of other libraries, but one of the blog posts said not do a library project because hackage already has too many and designing a good API from scratch is hard) GHC project ideas: - package improvements - finish multiple package stuff, sign and verify packages, ... - port GHC build system to shake (faster, progress indicators, written in Haskell, ...) - implement something like ccache or distcc for GHC - rewrite the GHC pattern overlap/exhaustiveness analysis ( https://ghc.haskell.org/trac/ghc/ticket/595, 10 years old!) - make GHC deterministic (refactor Unique + other nondeterminism sources, make a pure parser and/or typechecker API) - port Hat to the GHC api and integrate it into GHCi's :trace mode so omniscient debugging is available by default - implement typed core as another IL, either above or below old-core ("Types are Calling Conventions" paper) - other type-level programming library/project (units, extended arithmetic solver, true dependent types, linear types, ...) GHC backend-ish: - customizable RTS - remove unused RTS functions, write your own concurrency primitives, ... - resurrect Immix patches and try to get incremental GC - implement loop unrolling in GHC - allow LLVM phases to be written in Haskell (bindings already used, so it's just dealing with the FFI's and GHC's options handling...) I've tried putting these by two people (edwardk and carter) on #haskell-gsoc, and they both said that all the GHC ideas are too hard for a GSOC. Can I get a third opinion? Also, please tell me if I left anything important out (I see a Yi proposal on this mailing list; that would be in the ... in libraries). Finally, some sort of idea of which ideas are most likely to get accepted would be helpful. https://docs.google.com/forms/d/1rEobhHwFpjzPnra9L1TmrozWNFFyAVNPmdUMCcT--3… the top priorities are GHC, Cabal, and Hackage, so since GHC is (apparently) out I guess that means I should look more at my Cabal, Hackage, and Hoogle ideas... is this sensible? -- Allan Gardner

4 4