
Löb and möb: strange loops in Haskell (2013) - improv32
https://github.com/quchen/articles/blob/master/loeb-moeb.md
======
nickdrozd
Loeb's theorem says that you can prove a statement S if you can prove that S
is implied by its own provability. It's actually a generalization of Goedel's
second incompleteness theorem (let S be a false statement like _0 = 1_ ). I
can see something in the article that looks like Loeb's theorem ( _f (f a - >
a) -> f a_, reading _f_ as _it can be proved that_ ), but I don't know
Haskell, so I'm completely lost after that. Can someone explain in non-Haskell
terms what's going on?

~~~
moomin
Probably not, but since no-one else is having a go, I will: f is “Functor”,
which means roughly the same thing as in category theory (but restricted to
the domain of Haskell types). I’m guessing it’s possible to construct a
Provability functor.

-> in Haskell is just a function. I’ll mention that types and propositions have a structure preserving isomorphism. So “a” is an arbitrary type but you can think of it as an arbitrary proposition.

But equally, this holds true for all Functors, so we can specialise the
function to something like

(List (List Int -> Int) -> List Int

I hope this helps, it might not.

------
moomin
I wrote an article based on this one:
[https://colourcoding.net/2018/03/29/marvellous-
moeb/](https://colourcoding.net/2018/03/29/marvellous-moeb/)

I think one thing it’s super good for is constructing cyclic graphs from flat
representations: you don’t need to do cycle detection. (The example in the
code, sadly, does need cycle detection and doesn’t have it. I keep meaning to
write a follow-up.)

------
arciini
When (from an engineering, not personal curiosity perspective) is it
worthwhile to use loeb?

After reading the article for about 15 minutes, I finally understand loeb and
it's pretty cool! It's an easy way to actually run a list of lazy-loading
statements (functions) in a way that all of them resolve to their eventual
values.

That being said, it feels like the function is both too abstract to
understand, yet not effective as an abstraction that I can apply to other
problems. For a few contrasting examples, reverse_string is not a very
abstract function, as it operates on a very concrete operand and produces an
effect that's intuitive outside of mathematical theory. On the other end, a
hash table is very abstract, but we choose to learn it because it's such an
useful solution.

As for loeb, I only understand how to use it to create a spreadsheet, yet it's
clearly meant for more than that since it's given such an abstract name. It's
also not called evaluate_lazy_functions_on_operands either so it must be more
than that too! Is there something I'm missing?

~~~
cryptonector
Spreadsheets are basically a dependency resolution system, since you have to
inspect all cells to decide the order in which to evaluate them. So perhaps
loeb is just that, a sort of a SAT solver.

~~~
psergeant
> since you have to inspect all cells to decide the order in which to evaluate
> them

I don’t think this is true; evaluation order of a cell with no dependencies or
whose dependencies are already resolved shouldn’t matter

------
tempodox
> Feeling smart? Let's change that...

If I ever saw a description of Haskell in a nutshell, this is it. YMMV, of
course.

