The Future of Haskell Tooling

schedule Dec 14th 03:30 PM - 03:50 PM place Crystal 1 people 19 Interested

Haskell tooling, particularly editor and IDE integration has been sorely lacking for years. This talk will be a broad overview of the state of Haskell tooling, and the challenges faced by it. It will be derived from the experience of working on two summer of code projects trying to improve Haskell tooling.

For tooling users, we will discuss different Haskell tools available today(intero, haskell-ide-engine, ghcid etc.), their differences and trade-offs with respect to build tool support(stack, cabal, new-build, nix, make etc.), editor integration, features, limitations and speed.

We will go over the approach taken by haskell-ide-engine and the Language Server Protocol in order to solve these problems. Then we will discuss the new .hie file format designed to make information about Haskell source collected by GHC more accessible to tooling and users.

Finally, for budding tooling writers, we will discuss the various approaches to writing programs that extract information from and manipulate Haskell source, and their pros and cons:

  • The GHC API
    • Via ghc-mod and haskell-ide-engine
  • ghc-exactprint
  • haskell-src-extras
  • GHC source plugins
  • .hie files
 
4 favorite thumb_down thumb_up 9 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

  1. Introduction to haskell-ide-engine and the Language Server Protocol with a brief demonstration - 5 minutes
  2. Discussion of the architecture of haskell-ide-engine and what it brings to the table in terms of solving the Haskell tooling problem - 5 minutes
  3. Introduction to .hie files - a new, build tool independent way to get information out of GHC - 5 minutes
  4. Comparison of various approaches to write new Haskell tooling in 2018 - 5 minutes
  5. Questions - Remaining time, if any

Learning Outcome

For people who wish to use Haskell tooling, this talk offers a broad understanding of all the different moving pieces that go into making their tools work(or alternatively, why trying to set up reliable Haskell tooling usually results in pulling your hair out)

For people who wish to write new Haskell tooling or contribute to existing tools, an introduction to what you need to know, from an overview of all the different approaches that exist to getting information about haskell source, to how users will finally end up interacting with your tool.

Target Audience

People who have been frustrated by Haskell editor tooling

Prerequisite

Basic experience working with Haskell and haskell tooling.

schedule Submitted 5 months ago

Comments Subscribe to Comments

comment Comment on this Submission
  • Naresh Jain
    By Naresh Jain  ~  3 months ago
    reply Reply

    Hi Zubin,

    Would it be possible to condense this to a 20 mins talk? Focusing on point 4, 5 and 6 in your proposal? Point 1, 2 and 3 can be pre-req (read before the session)

    • Zubin Duggal
      By Zubin Duggal  ~  3 months ago
      reply Reply

      Sure, I could condense it down to 20 minutes but I would prefer a longer duration so that there is enough time for demonstration and questions.

      • Naresh Jain
        By Naresh Jain  ~  3 months ago
        reply Reply

        We want you to descope and only focus on point 4, 5 and 6 which comes up to 20 mins as per your proposal. Are you saying for point 4, 5 and 6 you would need more than 20 mins?

        • Zubin Duggal
          By Zubin Duggal  ~  3 months ago
          reply Reply

          I can discuss those topics in 20 minutes. However, some discussion of point 2 and 3 will probably be needed as motivation(especially for point 6). I could shorten/eliminate the live demonstration of HIE so that everything fits in the given time.

          • Naresh Jain
            By Naresh Jain  ~  3 months ago
            reply Reply

            How about detailing out point 2 and 3 as part of the proposal so people read that before they come to the session? To me the most valuable part of this session is the details around HIE and how it solves the problems, rather than a discussion on the problems itself.

            Please update your proposal to reflect what exactly you plan to do and based on that the committee will take a call.

            • Zubin Duggal
              By Zubin Duggal  ~  3 months ago
              reply Reply

              Ok, I've updated the outline in accordance with our discussion.

  • Naresh Jain
    By Naresh Jain  ~  3 months ago
    reply Reply

    Hi Zubin,

    Thanks for the proposal.

    Can you please update the outline with timewise breakup?

    Also, can you please share a video from your past presentation to help the program committee understand your presentation style?


    • Liked Michael Snoyman
      keyboard_arrow_down

      Michael Snoyman - Functional Programming for the Long Haul

      45 Mins
      Keynote
      Beginner

      How do you decide whether a programming language is worth using or not? By necessity, such decisions are usually based on assessments that can be made relatively quickly: the ease of using the language, how productive you feel in the first week, and so on. Unfortunately, this tells us very little about the costs involved in continuing to maintain a project past that initial phase. And in reality, the vast majority of time spent on most projects is spent in those later phases.

      I'm going to claim, based on my own experience and analysis of language features, that functional programming in general, and Haskell in particular, are well suited for improving this long tail of projects. We need languages and programming techniques that allow broad codebase refactorings, significant requirements changes, improving performance in hotspots of the code, and reduced debug time. I believe Haskell checks these boxes.

    • Liked Saurabh Nanda
      keyboard_arrow_down

      Saurabh Nanda - "Refresh-driven" development with Haskell & Elm

      Saurabh Nanda
      Saurabh Nanda
      Founder
      Vacation Labs
      schedule 5 months ago
      Sold Out!
      45 Mins
      Tutorial
      Beginner

      We sorely missed the rapid "refresh-based" feedback loop available in Rails (and other dynamically typed web frameworks), while writing Haskell. Change your code, hit save, and refresh your browser!

      In this talk we will share a few tips on how we finally hit productivity nirvana with ghcid and automated code-gen.

      Best of both worlds -- rock-solid type-safety AND being able to reload code with every change.

    • Liked Harendra Kumar
      keyboard_arrow_down

      Harendra Kumar - High Performance Haskell

      45 Mins
      Talk
      Intermediate

      Haskell can and does perform as well as C, sometimes even better. However,
      writing high performance software in Haskell is often challenging especially
      because performance is sensitive to strictness, inlining and specialization.
      This talk focuses on how to write high performance code using Haskell. It is
      derived from practical experience writing high performance Haskell libraries. We
      will go over some of the experiences from optimizing the "unicode-transforms"
      library whose performance rivals the best C library for unicode normalization.
      From more recent past, we will go over some learnings from optimizing and
      benchmarking "streamly", a high performance concurrent streaming library. We
      will discuss systematic approach towards performances improvement, pitfalls and
      the tools of the trade.

    • Liked Michael Snoyman
      keyboard_arrow_down

      Michael Snoyman - Applied Haskell Workshop

      Michael Snoyman
      Michael Snoyman
      Vice President of Engineering
      FP Complete
      schedule 6 months ago
      Sold Out!
      480 Mins
      Workshop
      Intermediate

      This full day workshop will focus on applying Haskell to normal, everyday programming. We'll be focusing on getting comfortable with common tasks, libraries, and paradigms, including:

      • Understanding strictness, laziness, and evaluation
      • Data structures
      • Structuring applications
      • Concurrency and mutability
      • Library recommendations

      By the end of the workshop, you should feel confident in working on production Haskell codebases. While we obviously cannot cover all topics in Haskell in one day, the goal is to empower attendees with sufficient knowledge to continue developing their Haskell skillset through writing real applications.

    • Liked Harendra Kumar
      keyboard_arrow_down

      Harendra Kumar - Streamly: Declarative Concurrency and Dataflow Programming in Haskell

      45 Mins
      Talk
      Intermediate

      Streamly is a Haskell library that marries monadic streaming and concurrency
      providing an elegant way of doing declarative concurrent dataflow programming.
      The Haskell ecosystem has some fine streaming libraries like pipes and conduit.
      However, these libraries are inherently serial and provide no support for
      concurrency within the streaming framework. Streamly is the first ever haskell
      streaming library that defines and implements concurrency semantics within
      a monadic streaming framework.

      The streaming API of Streamly is surprisingly simple, it is almost the same as
      standard Haskell lists, therefore, programmers do not need to learn a new DSL.
      By using specific concurrency-style combinators, streams can be generated,
      merged, chained, mapped, zipped, and consumed concurrently. Imagine your
      program as a pipeline of queues composed in a combination of serial and
      parallel configurations, and you can easily control which of these queues to
      run concurrently and at what rate. The degree of concurrency is auto scaled
      based on the feedback from the stream consumer, or based on a programmer
      specified rate limit. Moreover, Streamly does not trade performance with high
      level declarative concurrency, it provides excellent non-concurrent and
      concurrent performance.