Long story short - I'm in the midst of divorce (it sucks) and we got to the part in mediation where we're sorting out child support.
Without going into all the specifics - it dawned on me that the way contracts are done makes no sense!
In the best case scenario (which rarely happens but that's another story) - everyone agrees on a certain amount and that's written in.
But even in that best case- what happens when each person's income changes, child's needs like tuition changes, etc. You end up back in court or with lawyers re-writing the contract!
Again, that's in the best-case which rarely happens. More realistically, because it's a number that's written in - that number is the result of negotiation, compromise, and more often just not knowing better.
What I want to propose - and I need to figure out how to phrase it to non-programmers, is that really the legal agreement should be viewed as a FRP Monad! It's a function over continuous time, mapped with certain values as input parameters.
Those input parameters could be each spouses income, the children's expenses, etc.
The function is what needs to be debated and figured out in mediation - i.e. how much does relative income and potential earning sway the values... but it's all just pure functions.
Isn't that a cool idea? Instead of writing a value in the contract - I'm proposing that we write a function.
No idea if they'll go for it... and not sure if the lawyers are comfortable writing some Haskell into the contract 
but conceptually, this is I think the fairest way to get to an agreement that can also carry forward into the future (just call contract.sample() once a month!)
It can be very generous in the formation of the function too - this is about being up front and correct, not stingy. For example, there can be a calculated ratio of like one income dollar of spouse A is equal to 2 income dollars of spouse B. Whatever.
The point is to lazily evaluate the contract and only specify the function in writing...
