11 comments

[ 160 ms ] story [ 198 ms ] thread
"it can form the basis of automated verification and bug-finding tools for higher-order programs. "

Does this mean I can verify C++, Haskell, Python, JavaScript & Common Lisp code that uses Higher Order Functions?

That's the idea. We've only done it for Racket so far.
On page 3, I see this:

    (define/contract (f x)
    (positive? . âĘŠ . negative?) ; contract
    (* x -1))
Am I missing fonts or does âĘŠ actually mean something?
I see the same thing, but I think it's supposed to be a rightward arrow, as in a function from positive numbers to negative numbers. At least, that's how it usually appears in the Racket documentation.
(comment deleted)
It does appear to be some encoding issue relating to the Unicode "→" (U+2192). Encoded with UTF-8, this is represented by the three bytes 0xE2 0x86 0x92. In the TeX EC encoding, these correspond to "âĘŠ".

(See https://www.tug.org/TUGboat/Articles/tb11-4/tb30ferguson.pdf, also section 2.3 of http://mirrors.ctan.org/macros/latex/doc/encguide.pdf)

This is now fixed.
How is this different from defunctionalizing and converting to smt backend or prolog engine without higher-order capabilities?
I am looking for papers about converting to prolog backend. Could you name one for me? Thanks.
Other people have taken that approach, for example the HALO project in Haskell. But the imprecision of the defunctionalizaton often makes it hard to prove the properties you want, especially without static types.