On 2015-07-30 Nikita Karetnikov <nik...@karetnikov.org> wrote: > I have to admit the current mechanism implementation makes me uneasy. > Everything is mutable and some functions, like underfundedPatrons, do > too much, making it hard to test and even follow. > > When I start a new Haskell program, I usually try to express the core > idea with types, making illegal states unrepresentable. Then, I write > pure functions connecting the said types together, which compute the > result. IO is only used on the edges (to receive and send the data). > This is a very common technique. Can't we use it for the mechanism? > > How do you feel about this? I think the first step should be the > rigorous spec of the things we care about, i.e., anything touching > money. Then we follow the process described above. Testing becomes > trivial because the core stuff is pure while IO actions are just > reads/writes.
Sounds good to me (but I'm probably not the person to ask). I just wanted to express a little thought: One of the strengths of Haskell is the advanced type system and all the static verification it can give you. It means critical things can be verified statically instead of relying on tests to catch them (Yesod in general seems to take this approach seriously). All the m0ney related stuff is probably at least somewhat critical, so perhaps more work with types could replace some tests. Just a random idea, I don't know how the code actually works right now :P --- fr33domlover <http://www.rel4tion.org/people/fr33domlover> GPG key ID: 63E5E57D (size: 4096) GPG key fingerprint: 6FEE C222 7323 EF85 A49D 5487 5252 C5C8 63E5 E57D
signature.asc
Description: PGP signature
_______________________________________________ Dev mailing list Dev@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/dev
