Re:Learn Ethereum smart contract programming
by grogenaut on Monday July 24, 2017 @12:36PM
(#14839907)
I'm not sure static typing is tied to formal verification. In fact if you think about it most proofs are basically typeless I a lot of cases.
[ Parent
| on HN ]
Re:Learn Ethereum smart contract programming
by Cybiote on Monday July 24, 2017 @04:43PM
(#14842492)
Dependent or even refinement type systems are where a great deal of research into proof carrying code is done (for refinement types, since systems are restricted to decidability, the proofs are automatic but more limited).
Re:Learn Ethereum smart contract programming
by seanwilson on Monday July 24, 2017 @12:48PM
(#14840045)
What proof systems are you thinking about? Strong static types seem the most natural way to introduce formal verification into mainstream programming to me.
Re:Learn Ethereum smart contract programming
by tom_mellior on Tuesday July 25, 2017 @04:51AM
(#14846231)
(Not the parent here.) ACL2 is a prominent example of a proof assistant without a strong static type system; its object language is a pure subset of Common Lisp. The lack of static types is one of the reasons I find proving in ACL2 to be painful, but others have done amazing stuff with it.
Re:Learn Ethereum smart contract programming
by grogenaut on Monday July 24, 2017 @04:05PM
(#14842159)
Well general mathmatecial proofs or TLA+... or would it be better to define "integer" as a strong type which I'm willing to concede.
Re:Learn Ethereum smart contract programming
by seanwilson on Monday July 24, 2017 @07:51PM
(#14843816)
I don't feel there's much difference between e.g. the Coq way where types are used to bake specifications + proofs into the program and the Isabelle way where you write a program with less complex types and prove properties about the program after the fact.
General mathematical proofs? If you mean paper proofs they wouldn't be considered formal as they don't go down to the axiom level.