Give bools their own type in the module format (v6, 016 stage 1)

A condition was a number, non-zero being true: a flag was a number field,
a view showed 1 for true, and nothing kept a number from standing for a
bool or a bool from being added to. Now the verifier has a bool among its
stack types, and a verified module never mixes the two. No opcode is new:

- CONST with argument 1 is a bool (+0 or 1), NUM_TEXT with argument 1
  writes one as true or false; LOAD and STORE take a number or a bool
  state, locals may hold a bool (2).
- Comparisons (LT to NE, TEXT_COMPARE) and LIST_HAS give a bool; AND, OR
  and NOT take and give them; JZ, REQUIRE, filters and folds' tests take
  one (count and first leave a bool, sum, max, min and distinct a number
  and a bool); EQ and NE compare two bools too.
- Type codes: state 5, record field 2, message field 6 (one byte in the
  prefix, 0 or 1, or the message fails as limit), view 3. A bool's
  constant, initial value and default are +0 or 1; a list is not keyed by
  one. PUREMOD6: v5 modules are built again.

At run time a bool is a number's 0 or 1, so leaf-at-a-time folds run as
before. A number that becomes a bool (a module replaced, a stored state
or item read again, a waiting send recast) keeps 0 (either sign) and 1
and takes the default otherwise; a bool that becomes a number is 0 or 1.

The host carries bools on every boundary: JSON true and false only (a
row's field too), a query's true and false, true and false in views,
table JSON and HTTP deliveries; a link takes a bool only into a bool.

A stored outbox's field types were read back with a check that refused
bool (at or past rows): a node whose output had a bool field and a send
waiting could not start again. test-module now stores such a send and
opens it (it fails on the old check), beside 28 bool refusals of the
verifier and bool states, fields, views, sends, links and migration.
The lane generator makes numbers and bools apart.

0 files changed, 0 insertions, 0 deletions