Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I've been very excited about this myself before, but unfortunately, it's something of a stupid trick. The big problem is circular dependencies: they produce infinite loops and there's no particularly good way of detecting them. Regular old catamorphisms with `Either CycleDetected a` are probably a better idea in practice.


Can you elaborate on what kind of circular dependencies are you referring to and how would catamorphisms with `Either CycleDetected a` help to reduce those dependencies?


Okay, imagine you've got a list of securities and their underlyers. You've got a flat file that represents this information. You try to represent it as

Security Underlying Security (Security)

Where that's the Security object, not the Security ID.

This works great for moeb, until the day that someone accidentally introduces a cycle. Instead you want a representation that looks like:

Security Either CycleDetected a

You can call traverse to make that `Either CycleDetected Security a`.

Is that making any sense at all?

You rapidly realize that X knows Y and Y knows X.


Can you do that without losing all the fun of the magic one-liner with Haskell's inbuilt graph reduction? Otherwise, you may as well use Python ;-)


You gain all the fun of Fix, though.


Can you detect cycles in general though? At first blush it feels like a halting problem.


You can't detect all possible cycles statically, but you can definitely detect them when they happen at runtime. When calculating a value, track its dynamic dependencies. If it ends up depending on itself, you have a cycle.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: