4.3BSD-Tahoe/usr/src/bin/awk/EXPLAIN

Nov 30, 1979:

Awk has been modified yet again, in an attempt to make
its behavior more rational and predictable in the areas
of initialization, comparison, and type coercion.
Herewith what we believe the current truth to be:

1. Each variable and field can potentially be a string
or a number or both at any time.
When a variable is set by the assignment
	v = expr
its type is set to that of expr.  (This includes +=, ++, etc.)
An arithmetic expression is of type number, a
concatenation is of type string,  and so on.

If the assignment is a simple copy, as in
	v1 = v2
then the type of v1 becomes that of v2.

2. In comparisons, if both operands are numeric,
the comparison is made numerically.  Otherwise,
operands are coerced to string if necessary, and
the comparison is made on strings.

3. The type of any expression can be coerced to
numeric by subterfuges (kludges?) such as
	expr + 0
and to string by
	expr ""
(i.e., concatenation with a null string).

4. Uninitialized variables have the numeric value
0 and the string value "".  Accordingly, if x is
uninitialized,
	if (x) ...
is false, and
	if (!x) ...
	if (x == 0) ...
	if (x == "") ...
are all true.  But note that
	if (x == "0") ...
is false.

5. The type of a field is determined by context
when possible; for example,
	$1++
clearly implies that $1 is to be numeric, and
	$1 = $1 "," $2
implies that $1 and $2 are both to be strings.
Coercion will be done as needed.

In contexts where types cannot be reliably determined, e.g.,
	if ($1 == $2) ...
the type of each field is determined on input by
inspection.  All fields are strings; in addition,
each field that contains only a number (in the
sense of Fortran, say) is also considered numeric.
This ensures (for better or worse) that the test
	if ($1 == $2) ...
will succeed on the inputs
	0	0.0
	100	1e2
	+100	100
	1e-3	1e-3
and fail on the inputs
	(null)	0
	(null)	0.0
	2E-518	6E-427
as we believe it should.

Fields which are explicitly null have the string
value ""; they are not numeric.
Non-existent fields (i.e., fields past NF) are
treated this way too.

As it is for fields, so it is for array elements
created by split(...).

6. There is no warranty of merchantability nor any warranty
of fitness for a particular purpose nor any other warranty,
either express or implied, as to the accuracy of the
enclosed materials or as to their suitability for any
particular purpose.  Accordingly, the AWK Development
Task Force assumes no responsibility for their use by the
recipient.   Further, the Task Force assumes no obligation
to furnish any assistance of any kind whatsoever, or to
furnish any additional information or documentation.