Modern software is often designed to run on a virtual machine, such as the JVM or .NET’s CLR. Increasingly, even the web browser is considered a target platform with the Javascript engine as its virtual machine. The choice of programming language for a project is therefore restricted to the languages which target the desired platform. As a result, an important consideration for a programming language designer is the platform to be targetted. For a language to be truly cross-platform, it must not only support different operating systems (e.g. Windows, OSX and Linux) but it must also target different virtual machine environments such as JVM, .NET, Javascript and others. In this paper, I describe how this problem is addressed in the Idris programming language. The overall compilation process involves a number of intermediate representations and Idris exposes an interface to each of these representations, allowing back ends for different target platforms to decide which is most appropriate. I show how to use these representations to retarget Idris for multiple platforms, and further show how to build a generic foreign function interface supporting multiple platforms.

Constructive comments and suggestions are welcome, particularly if you’ve tried implementing a code generator for Idris.

]]>https://edwinb.wordpress.com/2015/07/04/cross-platform-compilers-for-functional-languages/feed/4edwinPractical Erasure in Dependently Typed Languageshttps://edwinb.wordpress.com/2015/02/28/practical-erasure-in-dependently-typed-languages/
https://edwinb.wordpress.com/2015/02/28/practical-erasure-in-dependently-typed-languages/#commentsSat, 28 Feb 2015 15:13:03 +0000http://edwinb.wordpress.com/?p=295]]>Matus Tejiscak and I have produced a new draft paper titled Practical Erasure in Dependently Typed Languages, in which we explain how Idris erases computationally irrelevant parts of programs. The abstract is:

Full-spectrum dependently typed languages and tools, such as Idris and Agda, have recently been gaining interest due to the expressive power of their type systems, in particular their ability to describe precise properties of programs which can be verified by type checking.

With full-spectrum dependent types, we can treat types as first- class language constructs: types can be parameterised on values, and types can be computed like any other value. However, this power brings new challenges when compiling to executable code. Without special treatment, values which exist only for compile-time checking may leak into compiled code, even in relatively simple cases. Previous attempts to tackle the problem are unsatisfying in that they either fail to erase all irrelevant information, require user annotation or in some other way restrict the expressive power of the language.

In this paper, we present a new erasure mechanism based on whole-program analysis, currently implemented in the Idris programming language. We give some simple examples of dependently typed functional programs with compile-time guarantees of their properties, but for which existing erasure techniques fall short. We then describe our new analysis method and show that with it, erasure can lead to asymptotically faster code thanks to the ability to erase not only proofs but also indices.

There has been significant interest in recent months in finding new ways to implement composable and modular effectful programs using handlers of algebraic effects. In my own previous work, I have shown how an algebraic effect system (called “effects“) can be embedded directly in a dependently typed host language. Using dependent types ought to allow precise reasoning about programs; however, the reasoning capabilities of effects have been limited to simple state transitions which are known at compile-time. In this paper, I show how effects can be extended to support reasoning in the presence of run-time state transitions, where the result may depend on run-time information about resource usage (e.g. whether opening a file succeeded). I show how this can be used to build expressive APIs, and to specify and verify the behaviour of interactive, stateful programs. I illustrate the technique using a file handling API, and an interactive game.

I’ve just submitted this, although constructive comments and suggestions are still of course very welcome!

Dependently-typed languages allow precise types to be used during development, facilitating reasoning about programs. However, stronger types bring a disadvantage that it becomes increasingly difficult to write programs that are accepted by a type checker and additional proofs may have to be specified by a programmer.

Embedded domain-specific languages (EDSLs) can help address this problem by introducing a layer of abstraction over more precise underlying types, allowing domain-specific code to be written in a high-level language which uses dependent types to enforce invariants without imposing additional proof obligations on an application programmer.

In this paper, we apply this technique to web programming. Using the dependently typed programming language Idris, we introduce an EDSL to facilitate the creation and handling of statically checked web forms, reducing the scope for programmer error and attacks such as SQL injection. We also show how to enforce resource usage protocols associated with common web operations such as CGI, database access and session handling.

You can find the accepted draft here. A revised version will appear later.

]]>https://edwinb.wordpress.com/2013/12/20/dependent-types-for-safe-and-secure-web-programming/feed/2edwinInteractive Idris editing with vimhttps://edwinb.wordpress.com/2013/10/28/interactive-idris-editing-with-vim/
https://edwinb.wordpress.com/2013/10/28/interactive-idris-editing-with-vim/#commentsMon, 28 Oct 2013 19:46:42 +0000http://edwinb.wordpress.com/?p=250]]>From Idris version 0.9.10 (and from now, if you’re tracking the git repository), the REPL provides various helpers for interactive editing. Agda users have known for a long time how useful this is, and I have become sufficiently jealous of it that I’ve decided it’s about time we had it too! I have implemented a short vim script to support interactive editing in vim, but since almost all of the work is done by the Idris REPL, it should be very easy to adapt to other editors. Here, I’ll briefly explain how to use it, then say a bit about how it works for anyone who might want to adapt it.

How to use it

Assuming you have an up-to-date Idris installed, install the vim Idris mode. This mode allows vim to communicate with a running Idris REPL instance. It provides the following basic commands:

\t displays the type of the name under the cursor (or a bit more information about its context if it happens to be a metavariable)

\e prompts for an expression to evaluate

\r reloads and typechecks the file in the current buffer

More interestingly, it provides support for interactive editing:

\c, if the cursor is over a variable in a pattern match clause, splits that variable into all the patterns which are well typed. This also works in case
expressions.

\w, if the cursor is over a pattern clause of the form f x y z = ?rhs creates a new with clause, i.e. the clause becomes:

f x y z with (_)
f x y z | with_pat = ?rhs

\d, if the cursor is in a top level function type declaration (right of the :), creates a new clause for that function.

(With all of these, the \ (backslash) is your local leader key. I have this rebound to , (comma) but \ is the default.)

Example: Case splitting

For example, start up idris vadd.idr (this will create the file if it doesn’t already exist) edit it with :e and type the following:

module vadd
vadd : Num a => Vect n a -> Vect n a -> Vect n a

Press ESC, and before moving the cursor anywhere, hit \d. You should see:

Now that you have the canonical proof, the left hand side has been updated so that x and y are unified to x. I’ll leave the rest of this definition as an exercise — remember to use \t to check the types of isElem_rhs_3 and isElem_rhs_4.

How it works

When an Idris REPL starts, it also starts up a server running on port 4294 your local machine, responding to requests from a REPL client. This can be queried using the --client flag to Idris. For example, from the shell:

There is also a destructive version :cs! which is the same, but updates the source file.

:addclause [line] [name], abbreviated :ac which displays a clause suitable for the function declaration for [name] on line [line]. Similarly, :ac! updates the source file.

:makewith [line] [name], abbreviated :mw which adds a with clause for the definition of [name] on line [line]. Again, :mw! updates the source file.

The vim script is simply a thin wrapper for these functions. It also uses the REPL to invoke the evaluator, and to call :r for quickly type checking a buffer.

Enjoy! If you prefer to use another editor, please consider contributing a similar script to support interactive development in your own editor. More features are planned, in particular automatically solving metavariables where possible.

We propose a dependently typed formalization for a simple class of sequential decision problems. For this class of problems, we implement a generic version of Bellman’s backwards induction algorithm and a machine checkable proof that the proposed implementation is correct. The formalization is generic. It is presented in Idris, but it can be easily translated to other dependently-typed programming languages. We conclude with an informal discussion of the problems we have faced in extending the formalization to generic monadic sequential decision problems.

]]>https://edwinb.wordpress.com/2013/06/25/sequential-decision-problems-dependently-typed-solutions/feed/0edwinProgramming and Reasoning with Algebraic Effects and Dependent Typeshttps://edwinb.wordpress.com/2013/03/28/programming-and-reasoning-with-algebraic-effects-and-dependent-types/
https://edwinb.wordpress.com/2013/03/28/programming-and-reasoning-with-algebraic-effects-and-dependent-types/#commentsThu, 28 Mar 2013 00:20:40 +0000http://edwinb.wordpress.com/?p=229]]>I have just submitted a new paper to ICFP 2013:

One often cited benefit of pure functional programming is that pure code is easier to test and reason about, both formally and informally. However, in order to be useful, programs must interact with the outside world. Haskell solves this problem using monads to capture details of possibly side effecting computations — it provides monads for capturing State, I/O, exceptions, non-determinism, libraries for practical purposes such as CGI and parsing, and many others, as well as monad transformers for combining multiple effects.

Unfortunately, useful as monads are, they do not compose very well. Monad transformers can quickly become unwieldy when there are lots of effects to manage, leading to a temptation in larger programs to combine everything into one coarse-grained state and exception monad. In this paper I describe an alternative approach based on handling algebraic effects, implemented in the Idris programming language. I show how to describe side effecting computations, how to write programs which compose multiple fine-grained effects, and how, using dependent types, we can use this approach to reason about states in effectful programs.

]]>https://edwinb.wordpress.com/2013/03/15/idris-course-at-itu-slides-and-video/feed/0edwinOn Partial Functions in Idrishttps://edwinb.wordpress.com/2013/02/19/on-partial-functions-in-idris/
https://edwinb.wordpress.com/2013/02/19/on-partial-functions-in-idris/#commentsTue, 19 Feb 2013 11:53:54 +0000http://edwinb.wordpress.com/?p=203]]>I had an email from a student asking why Idris supported partial functions, saying that it was surprising that a dependently typed language supported partial functions, because types are supposed to be precise specifications and you can’t be sure you have a precise implementation if your functions aren’t total. This is a very good question, and my answer was quite long, so following these academic blogging tips, I’ll reproduce my answer here. The tl;dr version is that, while I agree totality is important and I aim to make all of my programs total (I don’t think I’ve ever wanted to write a function with neither terminates nor produces results occasionally, after all) it’s a bit more complicated than that in practice.

I’m going to use “total” in a fairly informal sense here. By “total function” I mean either:

A function which terminates for possible inputs, or

A function which is guaranteed to produce some output before making a recursive call

In particular, this means you can still write an interpreter or operating system, for example. That is, you can write programs which run forever, but at least they achieve something while doing so.

It is a good idea to aim to make all of your functions total, as David Turner argues – when functions are total, you really can believe that “well-typed programs don’t go wrong” because you know you’re going to get an answer eventually (or in the case of coinductive functions, you know you’re going to keep making progress). And, indeed, dependent types can help you achieve that goal because you can use the extra structure the types give you as additional evidence for the termination checker. Here is a nice example.

Then, of course, some programs are really proofs, that you never actually run but which do demonstrate some properties of other functions. In this case, it’s vitally important that they are total, to guarantee that you haven’t missed any cases, or relied on circular reasoning, and so every possible input leads to a proof object.

Having said all that, Idris still supports partial functions, for two main reasons.

Firstly, you can divide programs in general into two categories:

Programs you haven’t finished writing yet

Programs which are complete

The first category is significantly larger than the second. Even more so if you replace “Programs” with “Applications”.

In the case that your program isn’t finished yet, you don’t want your type checker shouting at you that it’s not finished, because you already know, but you still might want to test it (sometimes we like to run our programs, as well as read and write them, after all). You might want to try running a program even with an incomplete proof, to help you develop an intuition for how the proof might work, or even to see if there are test cases which might invalidate your hypothesis. Alternatively, you might have a nice natural recursive algorithm which is not obviously structurally recursive (the functional version of quicksort is an obvious example of this) and not want to hold up the development of the rest of your application while you develop the termination proof.

The fact that programs spend most of their lives in an unfinished state is one reason people are interested in gradual types, and why a recent GHC extension allows you to run programs with type errors. You don’t want to release software with type errors (or, in the case of an Idris program with an associated correctness proof, release software with an incomplete proof) but it might be convenient during development.

Secondly, I don’t believe it’s a language’s job to tell a program what level of precision their programs’ types should have. Rather, a language and its features are there to help a programmer do their job. If I want the language to help me write a totally correct program with a precise specification, then I certainly want a totality checker, but if I’m just writing a quick script to do a simple task, maybe I’d rather just get the job done. I would like the library code the script invokes to be total, but I might not be so bothered about the script itself, at first.

Related to this, remember that there’s more you can do with dependent types than prove functional correctness. Just being able to give types to more programs is already a benefit which doesn’t require programs to be total. Dependent types can help you write generic libraries – the Eff library is a developing example of this, as are embedded domain specific languages in general – where the library user is making use of dependent types without necessarily being aware of it.

Idris aims to be a general purpose programming language, rather than a theorem prover, so aims to support all uses of dependent types, or even to support programming with conventional types if that’s all you need, so the default is to support partial functions. If the goal was primarily to be a theorem prover, I think the opposite choice would have been appropriate. Whatever happens, though, functions are always checked for totality, and you can make partial functions a compile-time error by default with the “–total” flag.

If you want complete safety, you certainly have to work for it, and depending on your application that may be important. Sometimes, though, you just want to get things done. In that case, Idris will let you – but at least the type system and totality checker make it clear what assumptions you have made to do so.

]]>https://edwinb.wordpress.com/2013/02/19/on-partial-functions-in-idris/feed/2edwinIdris, a General Purpose Dependently Typed Programming Language: Design and Implementationhttps://edwinb.wordpress.com/2013/02/10/idris-a-general-purpose-dependently-typed-programming-language-design-and-implementation/
https://edwinb.wordpress.com/2013/02/10/idris-a-general-purpose-dependently-typed-programming-language-design-and-implementation/#commentsSun, 10 Feb 2013 12:29:57 +0000http://edwinb.wordpress.com/?p=200]]>I’m busy revising the “How Idris works” paper, and you can find the latest draft here. Any further comments on how to improve it would be most welcome! Abstract:

Many components of a dependently typed programming language are by now well understood, for example the underlying type theory, type checking, unification and evaluation. How to combine these components into a realistic and usable high level language is, however, folklore, discovered anew by successive language implementations. In this paper, I describe the implementation of a new dependently typed functional programming language, IDRIS. IDRIS is intended to be a general purpose programming language and as such provides high level concepts such as implicit syntax, type classes and do notation. I describe the high level language and the underlying type theory, and present a method for elaborating concrete high level syntax with implicit arguments and type classes into a fully explicit type theory. Furthermore, I show how this method, based on a domain specific language embedded in Haskell, facilitates the implementation of new high level language constructs.