0:00 / 0:00
#haskell#c++#parallelprogramming
C++Now 2017: Ryan Newton "Haskell taketh away: limiting side effects for parallel programming"
CppNow
39K subscribers • 42 videos on Hallway • Conference channel
- Recommended by 2 people: 1 on Lobsters and 1 in engineering communities.
- Presented by Ryan Newton
- Linked in the descriptionboostcon/cppnow_presentations_2017
Intermediate. Assumes working knowledge.
39K views9 years ago2 recommendations
Programming languagesSystems programmingFunctional programmingConcurrency and parallelismLanguage design and type systems
Ryan Newton explains how limiting side effects through advanced type systems in Haskell and C++ enables safer and more effective parallel programming.
cppnow.org — Presentation Slides, PDFs, Source Code and other presenter materials are available at: github.com/boostcon/cppnow_presentations_2017 — In designing parallel programming abstractions, taking away user capabilities is as important as granting them. In this talk, I'll explain the role of this idea in several different parallel programming libraries for Haskell, C++, and other languages--spanning from shared memory to big data. The Haskell language is an experiment in making purely functional programming practical, and, as such, much of its design stems from limiting where and how the user can employ side effects. Haskell is almost 30 years old, but is used more widely and changing more rapidly than ever before. It's an exciting time for programming languages that use advanced type systems to accomplish formal software verification, and Haskell sits in midst of this revolution: at a juncture where it draws from the latest ideas in theorem proving languages, while at the same time remaining a practical programming language. By clearing the canvas of unconstrained effects, Haskell and similar languages allow experimenting with specific combinations of effects that work well together: e.g., for transactional memory, deterministic parallelism, or accessing remote data sources. Haskell enforces these restrictions at compile time, via the type system. While C++ cannot limit a method's side effects directly through types, it is well suited to host embedded domain specific languages (EDSLs) that can incorporate the same ideas. I will argue for a notion of purity that has little to do with whether memory is updated in place or not. Rather, it has to with whether combinations of effects preserve determinism. I'll show how entire applications can become deterministic functions of their inputs, including I/O. Ultimately we can call entire C++ programs from inside a pure function in Haskell, without violating any rule of the type system or the language's runtime semantics. Finally, over the course of this talk I'll also describe some specific history where C++ has affected the evolution of Haskell, and where, conversely Haskell may have a few ideas to offer. Haskell and C++ are both old languages that nevertheless keep changing regularly. There are even some surprising contemporary commonalities; for example, C++ and Haskell are two of the best languages available for data baking. — Ryan is a functional programmer of 25 years, and is a member of the Glasgow Haskell Compiler steering committee. Ryan Newton received his Ph.D. in computer science from MIT in 2009, advised by Arvind and Samuel Madden. His thesis introduced techniques for efficiently distributing a single logical program over a sensor network. From 2009 through 2011, Ryan was a software engineer in the developer products division at Intel, where he worked on parallel programming tools for C++, including CilkPlus and CnC. Since 2011, Ryan leads a group of progWhy it's here
2 people recommend thispuffnfreshon Lobsters • Recommends
Haskell taketh away: limiting side effects for parallel programming
u/PegasusAndAcornin r/ProgrammingLanguages • Mentions
Block to the Future
For much of my programming career, my notion of a programming language blocks) mirrors what Algol introduced nearly 60 years ago as a way to slay goto-rich spaghetti code. Such structured blocks manage two things:
* single-entrance/single-exit control flows
* setting a lexical scope for allocating/freeing local variables
Such blocks are ubiquitous in programming languages, having evolved mostly in incremental ways over the intervening years, such as:
* The growing popularity of iterator-based "for" and pattern-matching control flow blocks and the rise, then decline, of the "try" block.
* Extending lexical scope for a block beyond local variables to "resources" (e.g.,…