Workshop on Programming Research in

Mainstream Languages (PRiML 2020)

Saarbrücken, Germany, Mon July 6th, 2020

PRiML 2020 will be held online as a Zoom meeting with live broadcast of talks; also via YouTube. Questions to authors will be collected via Slack, Zoom or Slido. Details on free registration are below.

About PRiML

The First Workshop on Programming Research in Mainstream Languages is co-located with the Thirty-Fifth Annual ACM/IEEE Symposium on Logic in Computer Science (LICS 2020) & the 47th International Colloquium on Automata, Languages and Programming (ICALP 2020) in Saarbrücken, Germany, in July, 2020.

The PRiML workshop will consist of invited talks by leading experts involved in programming language (PL) research within mainstream PLs.

PL research in mainstream languages, entails challenges beyond those encountered within the isolation of the laboratory. Mainstream PLs, are supported by their many users, who expect stability, but so too innovation – whether within the language itself, or its standard libraries. A mainstream PL needs to support the initial concept critique, subsequent implementations, political calculations, and, ultimate bureaucracy involved in the execution of full support for novel features – often across multiple implementations. All that debate is due to real concerns about feature interaction.

Performing PL research within a mainstream language can bring a hitherto proven research concept from the laboratory to a wider audience. Moreover, of course, the lack of isolation presents fresh challenges as new concepts must fund their own idiomatic expressions over the debate on feature interaction. One finds such expressions either within an existing PL or as a new PL with the funding or wherewithal to approach a mainstream audience.

On the other hand, the prototype PL crafted for experimenting with a research idea might have features remote from existing mainstream PLs. Choosing a mainstream PL to host the same research entails a fresh examination of the host’s features for their suitability for the research. The implication might be a very different feature set from the host or simulation to those of the prototype in the mainstream PL. Either way, the added benefit is solving the same research problem using a fresh set of features.

Final Programme

Each talk is broadcast live via Zoom, and followed by 10 minutes of questions. Questions are collected via Slack, Zoom, or Slido and presented live to each presenter via Zoom. A 5 minute break follows, before each subsequent talk. A recording of the live stream from the workshop is available here.

Speakers and Abstracts

  • Ralf Jung
  • Stacked Borrows: An Aliasing Model for Rust

    Type systems are useful not just for the safety guarantees they provide, but also for helping compilers generate more efficient code by simplifying important program analyses. In Rust, the type system imposes a strict discipline on pointer aliasing, and it is an express goal of the Rust compiler developers to make use of that alias information for the purpose of program optimizations that reorder memory accesses. The problem is that Rust also supports unsafe code, and programmers can write unsafe code that bypasses the usual compiler checks to violate the aliasing discipline. To strike a balance between optimizations and unsafe code, the language needs to provide a set of rules such that unsafe code authors can be sure, if they are following these rules, that the compiler will preserve the semantics of their code despite all the optimizations it is doing.

    In this work, we propose *Stacked Borrows*, an operational semantics for memory accesses in Rust. Stacked Borrows defines an aliasing discipline and declares programs violating it to have *undefined behavior*, meaning the compiler does not have to consider such programs when performing optimizations. We give formal proofs (mechanized in Coq) showing that this rules out enough programs to enable optimizations that reorder memory accesses around unknown code and function calls, based solely on intraprocedural reasoning. We also implemented this operational model in an interpreter for Rust and ran large parts of the Rust standard library test suite in the interpreter to validate that the model permits enough real-world unsafe Rust code.

  • Ivan Čukić
  • Linear types can save the API

    C++ is a language celebrated for its abstraction mechanisms that do not incur performance penalties at runtime. It is often used in many mission critical systems, games, and everywhere else where speed and safety are paramount.

    That does not mean all C++ programs are fast by default. One of the most time costly mistakes we can make in C++ is creating unnecessary copies. C++11 move semantics made a move into the right direction. The move semantics allow us to give away data that we no longer want to use to somebody else without the penalty of creating the copy and without the risk of data races due to data being shared between multiple entities.

    But, while generally cheaper than copying, moving is still not a free operation. For this reason, many people diss on the FP-style APIs as inefficient and create impure stateful APIs instead.

    We are going to cover "linear types" - an idea from Phil Wadler that was meant to simplify and optimize pure GC-based languages such as Haskell. We're going to show how the same concept that allows pure functional programming languages to efficiently "change the world" can improve software written in a traditionally imperative impure language such as C++. We will show that with linear types, the FP-style APIs do not need to be inherently slower than their impure imperative counterparts.

  • Vadim Zaytsev
  • Hidden Mainstream: The Mainframe Languages

    According to the Octoverse report, most new open source applications are developed in languages from the 1990s, the top 5 are: Javascript (1995), Python (1990), Java (1995), PHP (1995) and C# (2000). However, Gartner's research on proprietary software said that 15% of new applications in 2005, totalling over 5'000 MLOC, were written in COBOL (1959). There are over 220'000 MLOC of COBOL in existence, and that is all deployed acting software performing business critical tasks, like ATM swipes (95% of which end up running some COBOL code). Together with other languages typical for the mainframe, like PL/I, COBOL code supports 80% of all financial transactions. In other words, it is a quite pervasive and crucial family of languages, mainstream for proprietary codebases but rarely making it to academic research projects. A popular movement of the 1980s to move from COBOL towards more modern languages, ended up focusing too much on the conciseness of descriptions for typical solutions, and developing a number of "fourth generation languages", only enriching the language cocktail of the mainframe. Most of these 4GLs are still in use and are considered legacy (just 40 year old instead of 60 year old), and code is being migrated from them whenever possible.

    In this talk, we will go through an overview of typical mainframe languages and their features that make them both undesirable/unmaintainable and hard to migrate. There will also be examples of migration projects with their typical challenges, and possible research opportunities inspired by them. The presenter has worked for 5 years as an analyst, developer and CSO of the largest independent compiler company specialising in this kind of project.

  • Jeremy Singer
  • Python programmers have GPUs too

    Auto-parallelization fits the Python philosophy, provides effective performance, and is convenient for non-expert developers. Despite being a dynamic language, we show that Python is a suitable target for auto-parallelization. We show that staging dependence analysis is an effective way to maximize performance. We apply classical dependence analysis techniques, then leverage the Python runtime’s rich introspection capabilities to resolve additional loop bounds and variable types in a just-in-time manner. We use a cost model to predict which available target device will provide fastest execution time for each loop. In relevant cases, loop nest code is converted to CUDA kernels for GPU execution. We achieve orders of magnitude speedup over baseline interpreted execution and some speedup over CPU JIT-compiled execution, across 12 loop-intensive standard benchmarks.

  • Joël Falcou
  • Designing the future of computation the C++ way

    Numeric simulations have become a pillar of the Modern Scientific Method, replacing experiments altogether in some fields. Within this new paradigm, people writing science had to quickly change to writing software. As with any new endeavour, this change came with teething problems as few science experts are also expert in software design, development or even research. So called scientific software needs to be fast and developed quickly as the race to publications, patents or viable products is faster than ever. But how can our scientists become efficient in software design? Dynamic languages like Python, Matlab or R fill a niche by allowing non-computer scientists to write software quickly.

    So why turn to C++? Well, the resources required to do this kind of computation are not cheap and having to wait for results because software is slow is a bad experience. So why not use our good old, close to the metal, infrastructure language that is C++?

    In this talk we will explore why C++, in its latest incarnation of C++20, fits this bill. We will see how designing languages as libraries gives us the best of both worlds: a high level of domain abstractions as well as a high level of performance. We shall see that recent C++ standards draw their power from borrowing powerful concepts from classical languages; concepts such as higher order functions, code as data, and many more.

    Important Dates

    Proposal submission deadline: Friday June 5th
    Author notification: by Friday June 12th
    Workshop: Monday July 6th

    Submission of Proposals

    We are looking for talks about PL research within mainstream PLs. Prospective speakers should consider topics which:

    1. briefly report on PL research performed with a mainstream PL; and
    2. clearly outline the added value of the chosen PL(s) for the reported research.

    We invite contributions from innovators working with classic TIOBE programming language mainstays such as Java, C, C++, Python and C#. But so too we welcome maturing Stack Overflow darlings such as Rust, Swift, Go and beyond.

    Talk titles along with abstracts should be submitted by email to the program chairs. Contact details are below.


    Free registration is available for all LICS/ICALP 2020 Workshops. To register, choose the Free Sign-Up option, either on the LICS 2020 registration page here, or the ICALP 2020 registration page here.


    There will be no formal proceedings published. Accepted talks will include a title and abstract which will be made available through the workshop website prior to any early registration deadline.

    Program Chairs

    Seyed Hossein Haeri, Université Catholique de Louvain, Belgium
    Paul Keir, University of the West of Scotland, UK