Carl Mäsak

I slapped a "needs more design" on this issue, because that's my explanation of why it's stalled since its creation back in 2015 (*gasp*). Case in point, the previous comment...

Just driving by to say (again) that this issue is "CFG-compete", in the sense that compete information about the CFG is required to do a sufficient analysis for linting. Which...

> And then use the qualified names, like `@test.test` and `test.assert`. Nope on the latter; thinko. The "real name" of the prefix thus imported would be `test.prefix:assert` (and you're free...

I just realized that the `assertType` of #256 (which I'm implementing in 007 as we speak) is really a special case of `assert`. That is, instead of ``` assertType(n, Int);...

As I was reading [how to design co-programs](https://patternsinfp.wordpress.com/2018/11/21/how-to-design-co-programs/amp/), I was thinking maybe there should be a `@useCase` annotation or some such, iterating through all the possible _types_ of input and...

> The strength of `assert` (and a very nice use case for macros) is that when an assertion fails, enough information has been saved to give really specific diagnostics [The...

> * Only top-level functions are allowed to have the `@test` annotation. If a nested function has it, that's a (beautiful) compile-time error. This is in fact necessary because the...

I think as a pleasant side effect of `@test` being an annotation and statically analyzable, we'll be able to tell statically where the tests are and how many of them...

> `assert` is a prefix macro. No, it isn't, not with our tight prefixes at least. Same as https://github.com/masak/007/issues/300#issuecomment-401114664, it could be a term.

I know I've used `assert` throughout this issue, under the assumption that it's cute to make `assert condition` mean one thing outside of tests (`if !condition { stopWithAnError() }`) and...