Edwin Brady - Idris 2: Type-driven development of Idris | Code Mesh LDN 18

I don't know, some of that is at least starting to happen with Idris 2, though not in the exact way predicted: ▶ this video (Type Driven Development with Idris 2) Short summary of linked video: when your type system is powerful enough you can restrict the set of possible implementations to the point that the compiler can make a decent guess as to what the program should be to satisfy the type signature.

You don't need the tests. You need only the types. And especially you don't need "artificial dumbness", which does not understand code, and therefore won't produce correct results, but just an advanced programming language. Say hello to Idris! :-) ▶ this video

Idris lang seems awesome with the atom plugin. :) Did not use it yet but I hope it will get more attention. ▶ this video

Until yesterday it was officially called "Blodwen" a "prototype successor to Idris", so I assume the fact that it's now officially being called a "pre-alpha implementation of Idris 2" means it's somewhat closer to being ready, but is there some specific announcement about the exact significance of it being officially called Idris 2 now? Edit: Never mind, I found the official announcement on the Idris mailing list: link He says "No doubt I'll say more about this over the next few weeks," so it sounds like he's planning on making a more detailed announcement later. Edit 2: Also, as someone who hasn't been following Blodwen or how it's different from Idris 1, this looks like a good introduction: ▶ this video

Dependent types are types which depend on values. As an example, think of the cons procedure: (List A, A) -> List A. It takes a List of A's and an A and returns a List of A's. With dependent types you can write this as (List n A, A) -> List n+1 A. This tells us that cons takes a List of A's with length n and an A returns a List of A's with length n+1. Edwin Brady shows off some examples in Idris here[1]. I thought the matrix example was really impressive. [1] ▶ this video

Refinements embed a predicate that elements of the new type must pass. def Nat = Int: (|x| -> x >= 0) Dependent types allow types to be computed from functions (and depend on arguments, otherwise it seems they become just weird constants), def Five(as_type: String) -> NumericType(as_type): match as_type: "string" => "five" "int" => 5 "float" => 5.0f "double" => 5.0d _ => panic() // Unnecessary if you refine `as_type` from a String to an enum or a fixed set of strings. Dependent types seem weird, but they help making types first-class ( ▶ this video ) and gaining types like `Array<T, N>` that allow ensuring things are the right length, and define append/extend properly.

Interesting. I didn't notice any reference to Idris [1] but that was the first place I saw this style of development. [1] ▶ this video

SAT solvers are starting to be used as tooling for functional languages - Liquid Haskell uses one for refinement types[1], and Djinn uses one for suggesting functions given a type[2]. Similarly to Djinn, Edwin Brady gave a presentation on using an SMT solver to do live code suggestions/implementation inference in the successor to Idris[3]. [1] link [2] link [3] ▶ this video

Hoogle is pretty nice, and few other languages had an equivalent until quite recently. I'm hopeful that cool type-powered IDE features will start to arrive once haskell-ide-engine is a bit more stable. It's getting there! There are some pretty awesome IDE ideas in Haskell-ish languages like Idris [1], too. There is some movement towards dependent types in Haskell, so it might get similar features one day. [1] ▶ this video

> In the general-purpose programming context, imagine if you could give examples of a program output (domain data) along with a skeleton of a program (source file with incomplete parts) and ask a system to fill in the holes. This part reminds me of some of capabilities of the Idris compiler [1]. In an Idris program you can leave "holes" to stand in for incomplete parts of a program [2], and the compiler can infer various bits of code from types and holes. In a demo of the in-progress Idris 2 compiler [3], Edwin Brady refers to it as a "lab assistant" and shows it writing a whole function when given a function type. [1] link [2] link [3] ▶ this video

I agree about its availability. I think it's far more useful than you seem to, though. Reducing the problem space is huge. It's why macro programming (ala Lisp) is so dangerous. It's why I left Haskell for Python, and why I often wish I was using Idris[1], which pretty much reads your mind and writes what you meant. It's true of coding generally, but SQL programming especially, that there's a conceptually obvious, small space of reasonable programs, but because we're writing in text, we're free to roam over an enormous superspace of (occasionally) wrong or (usually) meaningless programs. [1] ▶ this video