top | item 20630319

Arend: Theorem Prover Based on Homotopy Type Theory by JetBrains

309 points| adamnemecek | 6 years ago |arend-lang.github.io | reply

114 comments

order
[+] ocfnash|6 years ago|reply
Wow, I am delighted to see this!

However I cannot find a precise reference for the chosen type theory.

E.g., is univalence a theorem in their type theory? I presume it is given that they say their language has "syntax similar to cubical type theory" but I could not say for sure.

What I'm looking for is a reference containing the actual typing rules, like this one for Coq: https://coq.inria.fr/refman/language/cic.html#typing-rules

rather than the syntax of the language used for building these terms.

[+] cjfd|6 years ago|reply
Yes, I came here to say precisely that. It looks like it has about the same things available as coq as far as syntax is concerned, so what are the differences?
[+] namelosw|6 years ago|reply
Wow. Finally a prover with serious IDE support.

I always believe this field would be very useful and evolving steadily in the industry. It just doesn't attract eyeballs like machine learning and blockchains.

[+] baron_harkonnen|6 years ago|reply
> It just doesn't attract eyeballs like machine learning and blockchains.

... yet. The next AI Winter is right around the corner. While there has been seriously amazing work coming out of ML, in industry there is an insane amount of resources being put into completely BS ML systems. Outside of FAANG there are many "fancy" ML projects in industry that are just continually accruing massive technical debt, and for no good reason. The number of deep neural networks being used for problems that can be solved with radically much more simple (and easier to debug and maintain) techniques is astounding. Right now there is a boom in complex and fragile a systems made by teams of PhD in non-engineering fields that don't know anything about system or software design.

In a few years these complex systems will need to be maintained and fixed and it will quickly become apparent that the vast majority of these projects are a huge business liability with minimal financial or engineering benefit. Expect a huge back lash against predictions coming from complex, non-interpretable linear algebra heaps.

The pendulum will swing back, and likely pretty hard (as always probably too hard). I'm not sure theorem provers will be the winner, but the general class of understandable, predicable, and explainable things will become more popular. It is quite possible that "my tool proves things are stable and work" will be a big sell in the next wave of tech.

[+] mirekrusin|6 years ago|reply
Proving systems are one of main areas of research in blockchain space; on different levels - at type level for contracts/vm, at consensus level regarding properties like liveness etc and at multiple cryptography levels ie. in area of zero knowledge computations.
[+] est31|6 years ago|reply
AI used to be about expert systems during the last AI hype before this one.
[+] davidgrenier|6 years ago|reply
And here I was thinking I could finally use something from them.
[+] dwohnitmok|6 years ago|reply
I can't tell if this is JetBrains trying to develop its own version of Microsoft Research, or if this is the humble beginnings of a project like Kotlin that it aims to put its weight behind. Both would be cool (and indeed it could be both), but the latter would be truly exciting and a potentially a huge leap forward for theorem proving and formal verification.
[+] yole|6 years ago|reply
This is a research project. At this time there are no plans to invest into it on the same level as we're investing in Kotlin.
[+] tom_mellior|6 years ago|reply
I found the language reference and see how to define types and expressions, but I can't find any examples of what proofs would look like. Has anyone dug in enough to link to an actual proof of something?

The documentation for \lemma (https://arend-lang.github.io/documentation/language-referenc...) suggests that you would just write Prop-typed functions, which is very tedious to do manually and even with automation is IMHO inferior to Coq-style tactics, which are themselves often inferior to Isabelle's Isar-style proofs.

[+] sriram_malhar|6 years ago|reply
A tutorial or a few example of proofs would be nice. How does the experience differ from using Coq?
[+] bayesian_horse|6 years ago|reply
Again the question: Why is this useful?

Is this just for programming language research? What kind of projects would you want to use this language for?

[+] meuk|6 years ago|reply
The premise of an axiomatized system is that you can "mechanically" check proofs. So you can also invert the question and ask "Why the hell do we still prove things by hand?".

The answer to that is that there are no good tools and no universally accepted common notation that is amendable to automatic proof checking yet. Those are problems that projects like this want to solve.

I applaud the effort really; it's hard work, and people tend to ask more critical questions ("What is it good for?" "Theorem proving is for academics only") than for any other type of program.

[+] ganzuul|6 years ago|reply
A shot in the dark: it could perhaps help in automatically optimizing algorithms by proving that the optimized version is equal to an easily written and reasoned about.
[+] bitL|6 years ago|reply
Kuklev @ Göttingen turned his research into a plugin? Great! Can we get one for VSCode as well please?
[+] bob1029|6 years ago|reply
JetBrains has been gaining a lot of stock with me lately. I recently discovered that Rider is an extremely compelling replacement for VS2019 (for C# codebases), and this kind of news is going to keep them on my radar for the foreseeable future.

As another poster said, it seems like they are trying to build their own version of Microsoft Research. It is also entirely feasible JetBrains wants to build out these concepts to further enhance their core products. Detecting and executing refactor opportunities across complex, strongly-typed codebases could have some synergy with this research and tooling.

[+] manigandham|6 years ago|reply
Rider is basically taking Resharper (their VS extension that has been around for years) and merging it into their own IntelliJ IDE platform. It removes the performance and integration limitations and is fantastic to use.
[+] kccqzy|6 years ago|reply
This is extremely exciting as very few functional languages have good IDE support. I'm quite excited to see how building in IDE-support from the get go would help things.
[+] UK-Al05|6 years ago|reply
These sorts of new functional languages coming out will be a boon for jetbrains. Imagine doing program synthsis in an ide?
[+] pmontra|6 years ago|reply
Knowing nothing about Homotopy Type Theory and looking at the language only for the way it looks:

1) Nice to see that the pipe is only a | and not |> like in Elixir. One character is better than two (and a Shift key.)

2) {- comment -} probably comes from another language (which one?) but I'm always surprised by the cleverness of language designers, even when there is no need for it.

3) The backslash before the keywords is a backslash, pun intended. Why is that necessary and why did somebody even think about it? Cleverness fails designers sometimes.

4) I like that this-is-a-valid-identifier. This_is_slower_to_type because of the shift keys. ThisIsNotMuchFaster.

Then I'm also wondering what the language is being used for now. Somebody else asked the same question and got downvoted but it looked like a honest question. Is it still borderline to research and will maybe influence mainstream languages or are we already unknowingly using some program written in Arend on our machines or somebody's else server?

[+] Shoue|6 years ago|reply
1) those are for pattern matching, or sum-type separators in data definitions. Also if `|` were to mean "pipe", it's actually a downgrade because the direction isn't clear. `|>` and `<|` show that they pass data to the right and left functions respectively. If it were `|` what would be the accompanying operator that passes data in the opposite direction? Unix pipe streams data, but these operators are actually function application, so I wouldn't conflate the two, the latter is a much simpler concept, `a |> f == f(a)` and `f <| a == f(a)`.
[+] CaptainBern|6 years ago|reply
> 2) {- comment -} probably comes from another language (which one?) but I'm always surprised by the cleverness of language designers, even when there is no need for it.

Haskell has {- -} style (multiline)comments.

[+] HerrMonnezza|6 years ago|reply
3) Backslash before keywords looks inspired by TeX to me.
[+] chenglou|6 years ago|reply
1) That's a pattern match. Nothing to do with pipe
[+] raverbashing|6 years ago|reply
"this-is-a-valid-identifier" isn't because you don't know if this is an algebraic expression or not. Not sure how this language disambiguates, if it's using spaces or some other symbol.
[+] bvrmn|6 years ago|reply
All "cleverness" usually comes from struggle with parser generator. It's too many languages in the wild with weird syntax due to lack of interest/skills in proper parser.
[+] JadeNB|6 years ago|reply
> The backslash before the keywords is a backslash, pun intended.

What is the pun? Or, I guess I mean, what is the meaning of the second occurrence of 'backslash'?

[+] _jn|6 years ago|reply
2): Haskell.
[+] dllthomas|6 years ago|reply
"Classes are just records with additional functionality, which makes them into a haskell-style type classes."

But (IIUC) without coherence?

[+] Blaisorblade0|6 years ago|reply
Good point, but never seen typeclass coherence with dependent types (in either Coq or the various versions of the Agda design). Not sure for Isabelle.
[+] karoofish|6 years ago|reply
i'm a little confused. Is this BY Jetbrains as the title says, or by another company? Its using the same style as the Jetbrains website and and says "By" but also says Arend?
[+] j88439h84|6 years ago|reply
JetBrains is a company and they made a product called "Arend"
[+] auggierose|6 years ago|reply
Chuckle. What an odd choice to use HTT for a JetBrains theorem prover.
[+] xvilka|6 years ago|reply
Too bad it is Java. What about using proper, native compiled language? Like Rust, or OCaml.