
Poi: Pragmatic point-free theorem prover assistant in Rust - adamnemecek
https://github.com/advancedresearch/poi
======
tom_mellior
Example:

    
    
        > (len . concat)(a, b)
        (len · concat)(a, b)
        (len · concat)(a)(b)
        (concat[len] · (len · fst, len · snd))(a)(b)
        (add · (len · fst, len · snd))(a)(b)
        <=>  add((len · fst)(a)(b), (len · snd)(a)(b))
        > add((len · fst)(a)(b), (len · snd)(a)(b))
        add((len · fst)(a)(b), (len · snd)(a)(b))
        add((len · fst)(a)(b))((len · snd)(a)(b))
        add(len(a))((len · snd)(a)(b))
        add(len(a))(len(b))
    

This raises a few questions:

1\. How is this supposed to be point-free? a and b are clearly arguments.
Wouldn't you replace them with obscure projection functions if you really
believed that being point-free was useful?

2\. What about this are inputs of the system, and what are the outputs? I'm
guessing > marks what the user input, and the other lines are rewrites
produced by the system. In that case, why did it stop after a few steps when
it was clearly able to continue?

3\. Don't you need induction to prove this theorem? Where is the induction
step? Where is the base case?

4\. Are some of the rewrites based on lemmas already proved and stored in the
system? If so, wouldn't it be useful to mark such rewrites?

------
YeGoblynQueenne

             not x not
          o ---------> o           o -------> path-space
          |            |           |
      and |            | or        |
          V            V           |
          o ---------> o           V
               not            computation
    
    

Huh? I don't get it. This is supposed to be DeMorgan's in this weird notation.
I know DeMorgan's but I don't get that diagram. I'm reading about path
semantics via the links in the github but it seems to me you need to already
have a bit of a background in a certain, shall we say, remote, area of either
mathematics of computer science, or the mathematics of computer science in
order to follow quickly without spending time going down wikipedia rabbit
holes.

Anyway, sounds like an interesting thing to spend some free time on. Thanks.

Oh, please do ELI5 if anyone can.

~~~
lmm
'not' and 'not x not' are paths, 'and' and 'or' are computations. ('not x not'
is just the path on a pair that applies 'not' to each of the two elements -
products are pairs, sums are either-or). Diagrams like this generally express
a theorem as the diagram commuting. So the theorem is that if you compute
'and' and then lift the result along the path 'not', that's the same as
lifting the input along the path 'not x not' and computing 'or'. More mind-
bendingly, but ultimately more powerfully, it's also the statement that if you
lift the whole computation 'and' along this kind of higher-level path that
applies 'not' to everything, the result is 'or'.

~~~
tom_mellior
> 'not' and 'not x not' are paths

What's a "path", though? Why is it not a computation to map 0 to 1 and 1 to 0?

~~~
lmm
In homotopy type theory, a path from a to b is a (topologically) continuous
function from [0, 1] that sends 0 to a and 1 to b. For booleans this
distinction doesn't matter because every function to booleans is continuous,
but in the general case not every correspondence is a path and you can't lift
things along an arbitrary correspondence.

But having looked at the reddit thread it sounds like this is some non-
standard usage and this dude is a crank.

~~~
tom_mellior
Thanks for the explanation. I can see how "not" fits this definition (as
opposed to "and" and "or") by the accident of being a unary function. Whatever
the author is trying to illustrate doesn't seem especially deep. Having looked
at some other scattered writings, I agree with them being a crackpot.

------
tathougies
Point-free paths sound similar to cubical type theory from HoTT. Is there a
relation?

Great work!

------
bo1024
This seems very cool, but I didn’t understand clearly what it is used for.
More spelling out of the purpose would help, and discussion of similar
software.

------
ternaryoperator
Sort of an unfortunate name collision with Apache Poi, which is one of the
largest projects at the Apache Software Foundation.

~~~
throwlaplace
this is the most pointless comment genre on hn.

who really has a problem disambiguating when searching with other keywords?
it's not like search engine are hashtables. have you ever been unable to find
the right thing after adding at most two keywords? even more likely that
google knows if you're searching for apache poi you're not interested in
theorem proving so they point you to the right entity immediately.

~~~
mhh__
It can be fairly annoying.

People love to name projects after things in physics (particles mainly) which
can make googling slightly annoying although luckily 99% of the results I'm
looking for are on stackexchange or arxiv.

