Re: Array vs. List context
Daniel Chetlin [Fri, 4 Aug 2000 00:22:44 +0000 (17:22 -0700)]
Message-ID: <20000804002244.A5924@ilmd.chetlin.org>

p4raw-id: //depot/perl@6522

pod/perlapi.pod
pod/perlcall.pod
pod/perlembed.pod
pod/perlfaq4.pod

index e0b7c2b..4a7573b 100644 (file)
@@ -478,7 +478,7 @@ Found in file op.h
 =item GIMME_V
 
 The XSUB-writer's equivalent to Perl's C<wantarray>.  Returns C<G_VOID>,
-C<G_SCALAR> or C<G_ARRAY> for void, scalar or array context,
+C<G_SCALAR> or C<G_ARRAY> for void, scalar or list context,
 respectively.
 
        U32     GIMME_V
@@ -579,7 +579,7 @@ Found in file gv.c
 
 =item G_ARRAY
 
-Used to indicate array context.  See C<GIMME_V>, C<GIMME> and
+Used to indicate list context.  See C<GIMME_V>, C<GIMME> and
 L<perlcall>.
 
 =for hackers
index 148b24b..94edd34 100644 (file)
@@ -201,8 +201,8 @@ As with G_SCALAR, this flag has 2 effects:
 
 =item 1.
 
-It indicates to the subroutine being called that it is executing in an
-array context (if it executes I<wantarray> the result will be true).
+It indicates to the subroutine being called that it is executing in a
+list context (if it executes I<wantarray> the result will be true).
 
 
 =item 2.
@@ -355,7 +355,7 @@ use of this flag.
 As mentioned above, you can determine the context of the currently
 executing subroutine in Perl with I<wantarray>.  The equivalent test
 can be made in C by using the C<GIMME_V> macro, which returns
-C<G_ARRAY> if you have been called in an array context, C<G_SCALAR> if
+C<G_ARRAY> if you have been called in a list context, C<G_SCALAR> if
 in a scalar context, or C<G_VOID> if in a void context (i.e. the
 return value will not be used).  An older version of this macro is
 called C<GIMME>; in a void context it returns C<G_SCALAR> instead of
@@ -806,7 +806,7 @@ Notes
 
 =item 1.
 
-We wanted array context, so G_ARRAY was used.
+We wanted list context, so G_ARRAY was used.
 
 =item 2.
 
index dce785e..1787e4b 100644 (file)
@@ -356,7 +356,7 @@ made.
    int matches(SV *string, char *pattern, AV **matches);
 
 Given an C<SV>, a pattern, and a pointer to an empty C<AV>,
-matches() evaluates C<$string =~ $pattern> in an array context, and
+matches() evaluates C<$string =~ $pattern> in a list context, and
 fills in I<matches> with the array elements, returning the number of matches found.
 
 Here's a sample program, I<match.c>, that uses all three (long lines have
@@ -434,7 +434,7 @@ been wrapped here):
 
  /** matches(string, pattern, matches)
  **
- ** Used for matches in an array context.
+ ** Used for matches in a list context.
  **
  ** Returns the number of matches,
  ** and fills in **matches with the matching substrings
index ecbd652..112b1ed 100644 (file)
@@ -370,7 +370,7 @@ you can.  Is that the pencil's fault?  Of course it isn't.
 The date and time functions supplied with Perl (gmtime and localtime)
 supply adequate information to determine the year well beyond 2000
 (2038 is when trouble strikes for 32-bit machines).  The year returned
-by these functions when used in an array context is the year minus 1900.
+by these functions when used in a list context is the year minus 1900.
 For years between 1910 and 1999 this I<happens> to be a 2-digit decimal
 number. To avoid the year 2000 problem simply do not treat the year as
 a 2-digit number.  It isn't.