March 2014 - Haskell-Cafe

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

[TFP2014] Final Call For Papers
by Peter Achten 11 Mar '14

11 Mar '14

--------------------------------- F I N A L C A L L F O R P A P E R S --------------------------------- ======== TFP 2014 =========== 15th Symposium on Trends in Functional Programming May 26-28, 2014 Utrecht University Soesterberg, The Netherlands http://www.cs.uu.nl/wiki/TFP2014/WebHome *** Submission for TFP 2014 is now open: please direct your browser to *** http://www.cs.uu.nl/wiki/TFP2014/PaperSubmission The symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming, taking a broad view of current and future trends in the area. It aspires to be a lively environment for presenting the latest research results, and other contributions (see below), described in draft papers submitted prior to the symposium. A formal post-symposium refereeing process then selects a subset of the articles presented at the symposium and submitted for formal publication. Selected revised papers will be published as a Springer Lecture Notes in Computer Science (LNCS) volume. TFP 2014 will be the main event of a pair of functional programming events. The other is the International Workshop on Trends in Functional Programming in Education (TFPIE). TFPIE will take place on May 25th. Its website is located at http://www.cs.uwyo.edu/~jlc/tfpie14/ The TFP symposium is the heir of the successful series of Scottish Functional Programming Workshops. Previous TFP symposia were held in Edinburgh (Scotland) in 2003, in Munich (Germany) in 2004, in Tallinn (Estonia) in 2005, in Nottingham (UK) in 2006, in New York (USA) in 2007, in Nijmegen (The Netherlands) in 2008, in Komarno (Slovakia) in 2009, in Oklahoma (USA) in 2010, in Madrid (Spain) in 2011, St. Andrews (UK) in 2012 and Provo (Utah, USA) in 2013. For further general information about TFP please see the TFP homepage. INVITED SPEAKERS TFP is pleased to announce talks by the following two invited speakers: John Hughes of Chalmers, Goteborg, Sweden, is well-known as author of Why Functional Programming Matters, and as one of the designers of QuickCheck (together with Koen Claessen); the paper on QuickCheck won the ICFP Most Influential Paper Award in 2010. Currently he divides his time between his professorship and Quviq, a company that performs property-based testing of software with a tool implemented in Erlang. Dr. Geoffrey Mainland received his PhD from Harvard University where he was advised by Greg Morrisett and Matt Welsh. After a two year postdoc with the Programming Principles and Tools group at Microsoft Research Cambridge, he is now an assistant professor at Drexel University. His research focuses on high-level programming language and runtime support for non-general purpose computation. SCOPE The symposium recognizes that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five article categories. High-quality articles are solicited in any of these categories: Research Articles: leading-edge, previously unpublished research work Position Articles: on what new trends should or should not be Project Articles: descriptions of recently started new projects Evaluation Articles: what lessons can be drawn from a finished project Overview Articles: summarizing work with respect to a trendy subject Articles must be original and not submitted for simultaneous publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or more experience-oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Topics suitable for the symposium include: Functional programming and multicore/manycore computing Functional programming in the cloud High performance functional computing Extra-functional (behavioural) properties of functional programs Dependently typed functional programming Validation and verification of functional programs Using functional techniques to reason about imperative/object-oriented programs Debugging for functional languages Functional programming in different application areas: security, mobility, telecommunications applications, embedded systems, global computing, grids, etc. Interoperability with imperative programming languages Novel memory management techniques Program analysis and transformation techniques Empirical performance studies Abstract/virtual machines and compilers for functional languages (Embedded) domain specific languages New implementation strategies Any new emerging trend in the functional programming area If you are in doubt on whether your article is within the scope of TFP, please contact the TFP 2014 program chair, Jurriaan Hage at J.Hage(a)uu.nl. BEST PAPER AWARDS To reward excellent contributions, TFP awards a prize for the best paper accepted for the formal proceedings. TFP traditionally pays special attention to research students, acknowledging that students are almost by definition part of new subject trends. A student paper is one for which the authors state that the paper is mainly the work of students, the students are listed as first authors, and a student would present the paper. A prize for the best student paper is awarded each year. In both cases, it is the PC of TFP that awards the prize. In case the best paper happens to be a student paper, that paper will then receive both prizes. FINANCIAL SUPPORT TFP is financially supported by the Department of Information and Computing Sciences of Utrecht University, NWO (Netherlands Organisation for Scientific Research), Well-Typed and Erlang Solutions. PAPER SUBMISSIONS Acceptance of articles for presentation at the symposium is based on a lightweight peer review process of extended abstracts (4 to 10 pages in length) or full papers (16 pages). The submission must clearly indicate which category it belongs to: research, position, project, evaluation, or overview paper. It should also indicate whether the main author or authors are research students. In the case of a FULL STUDENT paper, the draft paper will receive additional feedback by one of the PC members shortly after the symposium has taken place. For the preproceedings, papers can be in any format (inclduing LNCS, IEEE and ACM style), but papers submitted to the postrefereeing process must be in LNCS style, and are bound by the limitations on paper length. We use EasyChair for the refereeing process. IMPORTANT DATES Submission of draft papers: March 17, 2014 Notification: March 24, 2014 Registration: April 7, 2014 TFP Symposium: May 26-28, 2014 Student papers feedback: June 9th, 2014 Submission for formal review: July 1st, 2014 Notification of acceptance: September 8th, 2014 Camera ready paper: October 8th, 2014 PROGRAM COMMITTEE Peter Achten Radboud University Nijmegen Emil Axelsson Chalmers Lucilia Camarao de Figueiredo Universidade Federal de Ouro Preto Laura Castro University of A Coruna Frank Huch Christian-Albrechts-University of Kiel Matthew Fluet Rochester Institute of Technology Jurriaan Hage (chair) University of Utrecht Yukiyoshi Kameyama University of Tsukuba Andrew Kennedy Microsoft Research Tamas Kozsik Eotvos Lorand University Ben Lippmeier University of New South Wales Luc Maranget INRIA Jay McCarthy (co-chair) Brigham Young University Marco T. Morazan Seton Hall University Ricardo Pena Universidad Complutense de Madrid Alexey Rodriguez LiquidM Sven-Bodo Scholz Heriot-Watt University Manuel Serrano INRIA Sophia Antipolis Simon Thompson University of Kent Tarmo Uustalu Inst of Cybernetics David Van Horn University of Maryland Janis Voigtlaender University of Bonn

1 0

Haskell Hackathon in NYC, April 4-6 (last reminder)
by MightyByte 11 Mar '14

11 Mar '14

Greetings, We're just under a month out from the first Hac NYC, so I wanted to send out one more reminder to the community. For the full details see the previous announcement. http://www.haskell.org/pipermail/haskell-cafe/2014-January/112362.html Once again, if you plan on coming, you must officially register by filling out our registration form [1]. Other details for travel, lodging, etc can be found on the Hac NYC wiki [2]. And if you would like to give a talk, please let us know [3] so we can schedule them. We're looking forward to seeing you here. -The Hac NYC Team [1] https://docs.google.com/forms/d/1taZtjgYozFNebLt1TR2VnKv-ovD2Yv5sOdSZzmi_xF… [2] http://www.haskell.org/haskellwiki/Hac_NYC [3] http://www.haskell.org/haskellwiki/Hac_NYC/Talks

2 1

ANNOUNCE: San Diego Haskell User Group.
by Cesar Lopez 11 Mar '14

11 Mar '14

Hello everyone: I would like to announce the creation and meeting of the *San Diego Haskell User Group*, the first meeting will be held on Wednesday March 19th. 2014 at 60:30PM at MindTouch, Inc's office in downtown San Diego. Please join us! *Information about the group:* The San Diego Haskell User Group aims to bring together academics, hobbyists, and software developers to discuss real world usage of the Haskell programming language. You can follow us on twitter @loshaskelleros<https://twitter.com/loshaskelleros> Information about the first meeting. *Unconference style Haskell meeting #1:* http://www.meetup.com/SanDiegoHUG/events/168606962/ Cheers cesar

1 0

Fwd: On Haskell IDEs
by Michal Antkiewicz 10 Mar '14

10 Mar '14

Vagif, it's all about separation of concerns and low coupling. There's no point adding all possible functionality into GHCi because it'll become too big and most users won't use most of it (ever used MSoft Word?). The ecosystem can be architected in some service-oriented way, in which some tools will be data providers and others will provide some added layers of functionality. That does not imply that all tools will need to maintain their own independent copies of information about the project. There largest overlap, as far as I can see, is between ghc-mod and hdevtools. Both are proofs of concept. Maybe parts could actually be incorporated into GHCi. hsdev seems to be specialized to source file editing and should remain separate but it can use the other ones as data sources (incl. Cabal and GHCi). Re: wasted effort. I don't agree. hdevtools was made to make a point that running a process in the background which maintains data and answers queries is much more responsive to the user than otherwise. And it has proven that point. Now, GHCi can learn that lesson and provide something similar, if that indeed belongs to GHCi's scope. Finally, all this is just speculation since I don't know exactly what the actual overlap among the tools is. It might be smaller than we think. Cheers, Michal On Mon, Mar 10, 2014 at 3:44 PM, Vagif Verdi <vagif.verdi(a)gmail.com> wrote: > Sorry, i meant ghci not cabal. > > As for hsdev, in order to provide its features it will have to load and > keep track of entire project information which is already done by ghc-mod > and hdevtools separately. So you ushould see how much effort is wasted on > doing the same thing again and again in each of 4 different tools (ghci, > ghc-mod, hdevtools and hsdev) > > > On Monday, March 10, 2014 12:32:25 PM UTC-7, Niklas Hambüchen wrote: > >> On 10/03/14 18:41, Vagif Verdi wrote: >> > This is an excellent illustration of how fragmentation in this specific >> > area hurts community. Not only you are forced to use 3 different tools >> > (ghc-mod, hdevtools, cabal) each of which basically provides the same >> > service but in an incompatible and incomplete way. But you decided to >> > create yet another one instead of contributing to the ones you already >> > use (they are all open source) >> >> I'm not sure what you mean to say; ghc-mod and cabal certainly do not do >> the same. Hsdev doesn't either, and claiming that we don't contribute to >> these projects is strange. >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskel...(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > <mantkiew(a)gsd.uwaterloo.ca> -- Michal Antkiewicz, M.Sc., Ph.D Research Engineer Network for the Engineering of Complex Software-Intensive Systems (NECSIS) University of Waterloo http://gsd.uwaterloo.ca/mantkiew mantkiew(a)gsd.uwaterloo.ca

1 0

[GSOC] haskell-type-exts?
by Andy Morris 10 Mar '14

10 Mar '14

On the GSOC ideas page for haskell.org is haskell-type-exts[1], which—as the name may suggest :)—is a proposal for a typechecker for haskell-src-exts. It doesn't seem to have got much attention, having only a single comment from two years ago, and I haven't seen anyone talking about it here or elsewhere. I guess this is still something that would be useful, so unless anyone has a reason why not, I'd like to apply to do it. I'll probably start working on the application later today unless some objections surface :) (Is Niklas Broberg subscribed to this list? If so: would you still be willing to mentor this project?) [1] https://ghc.haskell.org/trac/summer-of-code/ticket/1620

3 2

Extensible Binary-Meta-Language libraries
by Mateusz Kowalczyk 10 Mar '14

10 Mar '14

Greetings, Does anyone know if there are any libraries to work with Extensible Binary Meta-Language (used by Matroska)? I find mentions of such a thing in IRC logs from years ago by a person going by ‘ksf’ but he/she has disappeared from IRC about 5 weeks ago and I can not find their e-mail address. Is anyone interested in such a library? I am planning to implement it anyway but it'd be nice to know if there's any interest. Thanks -- Mateusz K.

1 0

New Functional Programming Job Opportunities
by Functional Jobs 10 Mar '14

10 Mar '14

Here are some functional programming job opportunities that were posted recently: Developer at Northwestern University http://functionaljobs.com/jobs/8690-developer-at-northwestern-university Cheers, Sean Murphy FunctionalJobs.com

1 0

Fwd: facebook exception
by Corentin Dupont 08 Mar '14

08 Mar '14

Hi, I am posting here in case one of you got this error. It's an old bug in my game that I was never able to solve. I use happstack-authenticate, but when I select facebook to login with, I get: FacebookException {fbeType = " ()", fbeMessage = ""} However, it seems well configured. I put: facebookAuth = Credentials {appName = "Nomyx", appId = "161007670738608", appSecret = <my secret>} On the facebook website, I have the application configured: application Id: 161007670738608 secret key: <my secret> Display Name: Nomyx NameSpace: nomyx-app App Domains: www.nomyx.net URL: http://www.nomyx.net:8000/ Do you have any hints? Thanks a lot!! Corentin <http://www.nomyx.net:8000>

1 0