Тёмный

"Proof Theory Impressionism: Blurring the Curry-Howard Line" by Dan Pittman 

Strange Loop Conference
Подписаться 82 тыс.
Просмотров 12 тыс.
50% 1

The Curry-Howard Correspondence is the observation that there exists a correspondence between objects present in disparate formal systems. Once such instance of this correspondence is the conspicuous propositions-as-types notion, which draws correspondences between logical propositions and types in a programming language.
As another more specific instance, one could consider a program written in a traditional programming language like Rust, and its formal proof exercised in a language like Coq.
While this is a beautiful revelation in theory, in practice this line begins to look more like an impenetrable wall as it divides proof from program. This chasm prevents assurances that, beyond those that can simply be "observed" by a human, an implementation faithfully abides its proofs. The conventional solution to this problem is code extraction. However, in cases like safety-critical system software (e.g. avionics, medical devices, & autonomous vehicles), the languages and platforms targeted by extraction tools simply aren't an option. What if there was another way?
This talk explores some potential approaches to endow our production language, mostly Rust in this case (w/ a dash of Haskell), with the capabilities present in "provable" systems. These explorations will include spaces like totality, type-level programming, and dependent types. Ultimately drawing lines from the above explorations back to how one might write such a thing in the language of a proof assistant.
Speaker: Dan Pittman

Наука

Опубликовано:

 

13 окт 2018

Поделиться:

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист
Посмотреть позже
Комментарии : 12   
@IanKjos
@IanKjos Год назад
It would be fabulous to see an update after oh these many moons: How much success did the project see? Where is it used? Have the standards bodies figured out about toolchain integrity?
@ilyabobyr
@ilyabobyr 5 лет назад
It would be nice to hear the questions =)
@NikolajLepka
@NikolajLepka 4 года назад
Dependent types are the complex numbers of type theory. They fill a gap previously present, and is archaic enough that the layman will probably never interact with it
@user-es9qo9hx2r
@user-es9qo9hx2r Год назад
6:21 Lean4 extracts C programs although the extraction process doesn't seem to have been formally verified. There is also ATS-lang that builds proofs around existing C code.
@Yustynn
@Yustynn 2 года назад
Well that was incredible
@tricky778
@tricky778 5 лет назад
If a program loads an ECU such that the ECU draws too much current, the PSU voltage drops and a driver alert doesn't sound then would this fall under the problem of operational semantics in the same way as the example that deletes the filesystem? If so then, given people never seem to give load and memory activity/occupancy any consideration with denotational semantics, how are denotational and operational semantics different? Is it just a question of awareness? IE, if you are aware there are files and they can be absent then to consider them is denotational semantics and to ignore them wilfully is operational semantics - but if you're not aware then it's all denotational semantics?
@brandonlewis2599
@brandonlewis2599 4 года назад
Operational and denotational semantics are just different abstractions with the same end-goal: make it possible to formally verify your (non-trivial) program. It's just that certain language or hardware features are more-or-less awkward to model, and hence more or less likely to contribute to the semantic gap that the speaker is trying to minimize. TL; DR, there's (still) no holy grail, though things are (slowly) improving. The two approaches each lend themselves to different kind of systems, and you still can't have your cake and eat it too.
@brandonlewis2599
@brandonlewis2599 4 года назад
Eventually these lines of research will start to converge, and some deep results will show what the trade-offs are in a precise way. But until then, you have to try to wrap your head around all of it, and try to choose the best approach for the work you're doing. And yes, that as horrible as it sounds.
@a.s.9145
@a.s.9145 Год назад
25:20 25:54 if bugs come at big price (loss) - language with more (longer) typing (enforced correctness) needed. if bugs are costless (or acceptable) - language with less typing will do the job much quicker.
@hankigoe829
@hankigoe829 5 лет назад
5:00 The proof worked b/c 'lol' happens to be a palindrome. It would have failed on 'haha' :D
@dengan699
@dengan699 3 года назад
Didn't they already solved this problem with sel4 kernel? It has been fully proved, but written in C, not rust. Then auto translated into Isabelle /HOL.
Далее
"Propositions as Types" by Philip Wadler
42:43
Просмотров 125 тыс.
Type Theory for the Working Rustacean - Dan Pittman
19:24
skibidi toilet zombie universe 33 ( New Virus)
02:59
Просмотров 2,2 млн
skibidi toilet multiverse 039 (part 1)
05:29
Просмотров 6 млн
"Hackett: a metaprogrammable Haskell" by Alexis King
33:40
The Curry-Howard Correspondence
45:33
Просмотров 6 тыс.
Propositions as Types - Computerphile
17:46
Просмотров 97 тыс.