Refactor the test suite

[masak]

The test suite is currently structured into these files:

t/
  semantics/
    types.t (AAA)
    operators.t (6 x A, 5 x E)
    blocks.t (6 x A)
    variables.t (A)
    if-statement.t (AA)
    subroutines.t (8 x A)
    return.t (6 x A)
    for-loop.t (AAAA)
    while-loop.t (A)
    fibonacci.t (A)
    begin-blocks.t (A, 3 x P, 7 x O)
    type.t (6 x A)
    builtins.t (21 x A)
    constants.t (OOO)
    macros.t (A)
  syntax/
    elements.t (24 x T)
    corner-cases.t (9 x T, 15 x F)
    expr.t (9 x T)
    macros.t (OO)
    quasi.t (OO)
    errors.t (F)
    begin-time.t (O)
    custom-ops.t [still in a branch] (T, 2 x F, 5 x O)

The letters in parentheses mark individual test calls:

A  AST input, expect (runtime) stdout
E  AST input, expect (runtime) error
F  program text input, expect (compile-time) error
O  program text input, expect (compile-time & runtime) stdout
P  program text input, expect (compile-time) stdout
T  program text input, expect AST

The project started out with just A tests (in the semantics/ directory) and T tests (in syntax/). Later tests added E and F tests, which... fine.

Then, BEGIN blocks necessitated the P test, and then, the parser got access to the runtime, and then we got static lexpads and values surviving from compile time to runtime, and so we needed O test (and could in retrospect perhaps have done without the P kind)...

BEGIN blocks deliberately flaunt the compile/runtime subdivision. So do operators, constants and (especially) macros. I think in recognition of this, we should retire the original directory structure and not distinguish so heavily between syntax and semantics.

Dividing things by feature still makes sense to me. So I mostly like the test file names in the semantics/ directory, and suggest reorganizing most tests to be under them. Actually, perhaps put them in a features/ subdirectory instead, and then put fibonacci.t (and later, man or boy) under some other aptly named subdirectory.

It's nice when a project outgrows its original assumptions.

[masak]

Then, BEGIN blocks necessitated the P test, and then, the parser got access to the runtime, and then we got static lexpads and values surviving from compile time to runtime, and so we needed O test (and could in retrospect perhaps have done without the P kind)...

Indeed, c730955 removes the P type of test, unifying it with O.