Draft an fpm specification

[milancurcic]

I want us to get started on the specification document. It would describe the expected behavior of fpm. It wouldn't be a user documentation, although users could use it to diagnose fpm bugs. A spec would help define much needed tests that would catch various recently reported unhandled exceptions.

Rather than us writing a spec and then an implementation following that spec, I think the spec should evolve side-by-side as we implement and discover the preferred ways to do things. So it will very much be a living document.

I'm happy to start the first draft. In this issue, I'm merely asking for thumbs up if you agree, and if not let me know why.

@certik @everythingfunctional @LKedward @arjenmarkus @smeskos

[certik]

If it was me, I would be fine with the spec simply being the tests themselves. But I am not against having a separate document also, but in either case, from a practical perspective, we need the tests for sure. That is how we will ensure that the Haskell and Fortran versions actually work.

[milancurcic]

I agree about tests, but to write tests you need to know the expected behavior of the program. Writing a spec would force us to get clear on the expected behavior.

[certik]

That's fine with me.

[everythingfunctional]

To the extent we can, the tests should read very much like the spec. But I am in favor of starting with a spec right now, mostly because I believe there are aspects of the Haskell version that do not function exactly as we want. We should have a discussion about how to handle these situations before we start writing the tests.

[arjenmarkus]

I agree: having worked with fpm a bit more, I see how it works currently and how it sometimes conflicts with things I am used to. It is not so bad that fpm enforces a particular practice, but it should be clear what it accepts and that should match our intentions. Regards, Arjen Op di 21 jul. 2020 om 21:23 schreef Brad Richardson < notifications@github.com>:

…

To the extent we can, the tests should read very much like the spec. But I am in favor of starting with a spec right now, mostly because I believe there are aspects of the Haskell version that do not function exactly as we want. We should have a discussion about how to handle these situations before we start writing the tests. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#133 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN6YRY7GDQKFTCYFW3S2GTR4XTMVANCNFSM4PDXFU6A> .