BEGIN {print x[1]++}

In theory, this should print null (an empty string), because, prior to the
(post-) increment, the value of x[1] is "empty".  However, the generally
desirable behavior would be for it to print zero (0), and this is, in fact,
what seems to happen on (most) modern AWKs.  In fact, I couldn't find one
that didn't do this, including the infamous Sun /usr/bin/awk.

I have distinct memories, though, of using a PC (DOS) AWK, a million years
ago, that did print null.

On 2004-07-30, Kenny McCormack wrote:
> 	BEGIN {print x[1]++}
>
> In theory, this should print null (an empty string), because, prior to the
> (post-) increment, the value of x[1] is "empty".  However, the generally
> desirable behavior would be for it to print zero (0), and this is, in fact,
> what seems to happen on (most) modern AWKs.  In fact, I couldn't find one
> that didn't do this, including the infamous Sun /usr/bin/awk.
>
> I have distinct memories, though, of using a PC (DOS) AWK, a million years
> ago, that did print null.

   From "The AWK Programming Language", 1988:

       Like variables, array elements spring into existence by being
       mentioned; at birth, they have the numeric value 0 and the
       string value "".

-- 
    Chris F.A. Johnson                  http://cfaj.freeshell.org/shell
    ===================================================================
    My code (if any) in this post is copyright 2004, Chris F.A. Johnson
    and may be copied under the terms of the GNU General Public License

In article <2mvmnoFraakmU3@uni-berlin.de>,
Chris F.A. Johnson <cfajohnson@gmail.com> wrote:
>On 2004-07-30, Kenny McCormack wrote:
>> 	BEGIN {print x[1]++}
>>
>> In theory, this should print null (an empty string), because, prior to the
>> (post-) increment, the value of x[1] is "empty".  However, the generally
>> desirable behavior would be for it to print zero (0), and this is, in fact,
>> what seems to happen on (most) modern AWKs.  In fact, I couldn't find one
>> that didn't do this, including the infamous Sun /usr/bin/awk.
>>
>> I have distinct memories, though, of using a PC (DOS) AWK, a million years
>> ago, that did print null.
>
>   From "The AWK Programming Language", 1988:
>
>       Like variables, array elements spring into existence by being
>       mentioned; at birth, they have the numeric value 0 and the
>       string value "".

That contributes nothing (Or, in Homer Simpson terms, Duh!).

The point is this: If you left off the (post-) increment, it would print as
a null string (in your terms, 'the string value ""').  The presence of the
(post-) increment seems to cause it shift to a numeric context and thus
print 0, but I think this is technically wrong.  One of the more sticky
situations in life is when the observed behavior is the desirable behavior,
while the standards compliant behavior is less-than-optimal.

Kenny McCormack wrote:

> 	BEGIN {print x[1]++}
> 
> In theory, this should print null (an empty string), because, prior to the
> (post-) increment, the value of x[1] is "empty".  However, the generally
> desirable behavior would be for it to print zero (0), and this is, in fact,
> what seems to happen on (most) modern AWKs.  In fact, I couldn't find one
> that didn't do this, including the infamous Sun /usr/bin/awk.
> 
> I have distinct memories, though, of using a PC (DOS) AWK, a million years
> ago, that did print null.
> 

Why complicate the problem with an array? You get the same result with just:

	BEGIN{print i++}

Like you say, I'm glad that's what it does even if it does seem to go 
against the documented expectation.

	Ed.

On 2004-07-30, Kenny McCormack wrote:
> In article <2mvmnoFraakmU3@uni-berlin.de>,
> Chris F.A. Johnson <cfajohnson@gmail.com> wrote:
>>On 2004-07-30, Kenny McCormack wrote:
>>> 	BEGIN {print x[1]++}
>>>
>>> In theory, this should print null (an empty string), because, prior to the
>>> (post-) increment, the value of x[1] is "empty".  However, the generally
>>> desirable behavior would be for it to print zero (0), and this is, in fact,
>>> what seems to happen on (most) modern AWKs.  In fact, I couldn't find one
>>> that didn't do this, including the infamous Sun /usr/bin/awk.
>>>
>>> I have distinct memories, though, of using a PC (DOS) AWK, a million years
>>> ago, that did print null.
>>
>>   From "The AWK Programming Language", 1988:
>>
>>       Like variables, array elements spring into existence by being
>>       mentioned; at birth, they have the numeric value 0 and the
>>       string value "".
>
> That contributes nothing (Or, in Homer Simpson terms, Duh!).
>
> The point is this: If you left off the (post-) increment, it would print as
> a null string (in your terms, 'the string value ""').  The presence of the
> (post-) increment seems to cause it shift to a numeric context and thus
> print 0, but I think this is technically wrong. 

     Presumably the entire line has been parsed and the array element
     is being used numerically; therefore printing 0 is consistent.

     To quote the POSIX standard for AWK:

         Evaluation of variables with an uninitialized value, to
         either string or numeric, shall be determined by the context
         in which they are used.

     The context is numeric, even though the numeric operator hasn't
     yet been used.

> One of the more sticky situations in life is when the observed
> behavior is the desirable behavior, while the standards compliant
> behavior is less-than-optimal.


-- Chris F.A. Johnson http://cfaj.freeshell.org/shell
    ===================================================================
    My code (if any) in this post is copyright 2004, Chris
    F.A. Johnson and may be copied under the terms of the GNU General
    Public License

On Fri, 30 Jul 2004 20:08:25 GMT, gazelle@yin.interaccess.com (Kenny
McCormack) wrote:

>In article <2mvmnoFraakmU3@uni-berlin.de>,
>Chris F.A. Johnson <cfajohnson@gmail.com> wrote:
>>On 2004-07-30, Kenny McCormack wrote:
>>> 	BEGIN {print x[1]++}
>>>
>>> In theory, this should print null (an empty string), because, prior to the
>>> (post-) increment, the value of x[1] is "empty".  However, the generally
>>> desirable behavior would be for it to print zero (0), and this is, in fact,
>>> what seems to happen on (most) modern AWKs.  In fact, I couldn't find one
>>> that didn't do this, including the infamous Sun /usr/bin/awk.
>>>
>>> I have distinct memories, though, of using a PC (DOS) AWK, a million years
>>> ago, that did print null.
>>
>>   From "The AWK Programming Language", 1988:
>>
>>       Like variables, array elements spring into existence by being
>>       mentioned; at birth, they have the numeric value 0 and the
>>       string value "".
>
>That contributes nothing (Or, in Homer Simpson terms, Duh!).
>
>The point is this: If you left off the (post-) increment, it would print as
>a null string (in your terms, 'the string value ""').  The presence of the
>(post-) increment seems to cause it shift to a numeric context and thus
>print 0, but I think this is technically wrong.  One of the more sticky
>situations in life is when the observed behavior is the desirable behavior,
>while the standards compliant behavior is less-than-optimal.

If a variable can be a string or a number, and which it is depends on
the context, I would expect and uninitialized variable to be 0 in
arithmetic contexts and "" elsewhere.  Your example's context is
clearly numerical.



T.E.D. (tdavis@gearbox.maem.umr.edu)
SPAM filter: Messages to this address *must* contain "T.E.D." 
somewhere in the body or they will be automatically rejected.