88 lines
2.6 KiB
Plaintext
88 lines
2.6 KiB
Plaintext
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.
|