SPLV20 VS ATS-Postiats

Internally, the Idris2 compiler uses deBruijn numbering for its terms, which is tricky to get right once you start trying to manipulate terms. To help with this, it keeps a list of the names corresponding to the deBruijn indices at the type level. The type checker catches mistakes as you write code to manipulate them (inserting names, removing names, or renaming things).

I ran through some exercises teaching this technique[1]. My take-away as a beginner was that it was a pain to make the compiler happy and my code that the compiler didn't like was actually wrong.

I remember reading someone had written a functional red-black tree (with proof of correctness leveraging dependent types) and said the delete algorithm naturally followed from the types. That has was not my experience (delete wasn't immediately obvious to me), but I need to find some time to give it another go.

The Idris2 docs have an example of a lambda expression interpreter[2] whose terms have a vector of the types in the environment as a type parameter (erased at runtime), to ensure everything is type safe in the resulting interpreter.

Typescript has added some bits of dependent typing. For example, asserting a function returns true if the argument has type X, that a function throws if the argument is falsy, and I think type level string manipulation. They are fairly pragmatic, it's not a research language, so I presume that specific functionality is useful to a lot of people. I've used it a little bit of it to help the type checker infer non-null after my assert function was called.

All of that said, I think people are still exploring how dependent types can be used in practice.

[1]: https://github.com/edwinb/SPLV20/blob/master/Code/Lecture2/E...

This is one of my two favorite books in The Little ...er series. The other is The Rational Schemer. These are two of the most advanced books in the series.

The Little Typer provides an introduction to dependent types. These can by used to guarantee things like "applying 'concat' to a list of length X and list of length Y returns a list of X+Y". It is also possible, to some extent, to use dependent types to replace proof tools like Coq. Two interesting languages using dependent types are:

- Idris. This is basically "strict Haskell plus dependent types": https://www.idris-lang.org/)

- ATS. This is a complex systems-level language with dependent types: http://www.ats-lang.org/

The Rational Schemer shows how to build a Prolog-like logic language as a Scheme library. This is a very good introduction to logic programming and the implementation of backtracking and unification is fascinating.

This is an excellent series overall, but these two books are especially good for people who are interested in unusual programming language designs. I don't expect dependent types or logic programming to become widely-used in the next couple generations of mainstream languages, but they're still fascinating.

Not being ATS

> any safety checks put into the competing language will have a runtime cost, which often is unacceptable

This is completely wrong. The best counterexample is probably ATS http://www.ats-lang.org which is compatible with C, yet also features dependent types (allowing us to prove arbitrary statements about our programs, and check them at compile time) and linear type (allowing us to precisely track resource usage; similar to Rust)

A good example is http://ats-lang.sourceforge.net/DOCUMENT/ATS2CAIRO/HTML/c36.... which uses the Cairo graphics library, and ends with the following:

> It may seem that using cairo functions in ATS is nearly identical to using them in C (modulo syntatical difference). However, what happens at the level of typechecking in ATS is far more sophisticated than in C. In particular, linear types are assigned to cairo objects (such as contexts, surfaces, patterns, font faces, etc.) in ATS to allow them to be tracked statically, that is, at compile-time, preventing potential mismanagement of such objects. For instance, if the following line:

      val () = cairo_surface_destroy (sf) // a type error if omitted

For a low level language in which you actually need to prove that your code doesn't cause UB, see http://www.ats-lang.org/

Here's the homepage fo the language: http://www.ats-lang.org/. The trick to finding results about with google is to search "ATS programming language".

In SPARK's case, you have to state your invariants in even greater precision than in Rust, and naturally it has worse inference. That's okay, the same happens in a certain language with Atrocious Type Syntax.

Yes, things like mentioned in the post can be expressed and checked statically, as demonstrated by languages like Idris and ATS. ATS might be even more relevant as it's an imperative language too, it can get rather low-level (like talking about properties of C runtime functions) while proving required properties statically, and it includes a solver for certain amount of arithmetics so that you don't need to prove obvious mathematical identities to the compiler. http://www.ats-lang.org/