A few things that Pyret gets out of "where" blocks that it's not obvious are easy with just assertions after the function.
- Reporting failures can more easily report context about the function being tested
- Since "where" blocks are actual blocks, we define helper functions and variables inside them that don't need to clutter up the namespace of the current scope
- It's easy to turn the assertions on and off; for example when importing a Pyret module we skip running the checks of that module by default.
- The localized information also plays into our story for type inference (which is work in progress), but starts from the unit tests in the where: block to figure out what the programmer intended for input/output types.
Comments
A few things that Pyret gets out of "where" blocks that it's not obvious are easy with just assertions after the function.
- Reporting failures can more easily report context about the function being tested
- Since "where" blocks are actual blocks, we define helper functions and variables inside them that don't need to clutter up the namespace of the current scope
- It's easy to turn the assertions on and off; for example when importing a Pyret module we skip running the checks of that module by default.
- The localized information also plays into our story for type inference (which is work in progress), but starts from the unit tests in the where: block to figure out what the programmer intended for input/output types.