LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (August 2003, week 2)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:         Thu, 14 Aug 2003 16:54:16 -0400
Reply-To:     Ian Whitlock <WHITLOI1@WESTAT.COM>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Ian Whitlock <WHITLOI1@WESTAT.COM>
Subject:      Re: Twilight Zone: Array Implict or Explicit
Comments: To: "sashole@bellsouth.net" <sashole@bellsouth.net>
Content-Type: text/plain

Paul,

I suspect the twilight zone exists becasue of compatibility requirement with old code.

Remember that:

Array a a1-a3 ; Array a (_i_) a1-a3 ;

are not documented in current documentation. Hence you should not be surprised at any result obtained from the use of such code and should be happy when it does what you would like it to do. On the other hand, perhaps one shouldn't peek in the musty corners of the language except for fun.

IanWhitlock@westat.com

-----Original Message----- From: Paul M. Dorfman [mailto:sashole@BELLSOUTH.NET] Sent: Thursday, August 14, 2003 3:08 PM To: SAS-L@LISTSERV.UGA.EDU Subject: Re: Twilight Zone: Array Implict or Explicit

Ian,

What I do not understand is why the twilight zone should exist, and/or why the compiler should be left in dark as to its kind (not data type) after the array has been defined. The new documentation mentions neither of the

Array a a1-a3 ; Array a (_i_) a1-a3 ;

and unambiguosly states that an explicit array cannot be defined without defining its bounds in some way in parentheses (brackets) following the array name. On the other hand, the latest piece of SAS documentation treating implicit arrays (Version 6, First Edition) unequivocally states that both declaration shown above define an implicit array and implicit array only. As if to emphasise it further, the doc states: "Implicit arrays do not contain an explicit reference to the number of elements in the array" - obviously the case for both declarations above.

Thus, the two statements must be strictly equivalent for all intents and purposes and define an implicit array, and the only reaction by the compiler to an explicit array reference following either declaration must be

ERROR: Mixing of implicit and explicit array subscripting is not allowed.

Leaving the kind of the array (not the data type)

Array a a1-a3 ;

undetermined until later on in the step makes the language vague, because in lieu of any indication how the matter should be resolved in the documentation, the programmer is left at mercy of guess and trial. For example, as you have demonstrated in this thread, not every first explicit reference to the array A above makes it explicit. We may think it is only limited to A[_I_] in PUT or INPUT and even try finding logic behind these exceptions, but the fact is we do not know.

As I have already written, I like using implicitly subscripted arrays where they fit and make code more clear, but to avoid the twilight zone, I adhere to simple rules:

1) If the arrays is defined as implicit (i.e. without defining its bounds explicitly), reference it implicitly. Almost always, such use takes advantage of DO OVER.

2) Otherwise if array bounds are defined explicitly (that includes the [*] reference), reference array elements explicitly.

Kind regards, ======================= Paul M. Dorfman Jacksonville, FL =======================

> -----Original Message----- > From: Ian Whitlock [mailto:WHITLOI1@WESTAT.com] > > Paul, > > I don't think you understand the twilight zone. > > In > > Array a a1-a3 ; > > the compiler is still in the twilight zone, i.e. the wave has not > collapsed, and the array may be either implicit or explicit. > > In > > Array a (_i_) a1-a3 ; > > there is no twilight, i.e. the wave has collapsed, and the array must > be implicit. Hence the two statements are as different as night and > day, as you have demonstrated below. > > IanWhitlock@westat.com > > -----Original Message----- > From: Paul M. Dorfman [mailto:sashole@bellsouth.net] > Sent: Thursday, August 14, 2003 12:07 PM > To: Ian Whitlock; SAS-L@LISTSERV.UGA.EDU > Subject: RE: Twilight Zone: Array Implict or Explicit > > > > -----Original Message----- > > From: Ian Whitlock [mailto:WHITLOI1@WESTAT.com] > > > > Paul, > > > > The error messages are correct! > > > > 797 put x(j)= ; > > - > > 79 > > 76 > > ERROR 79-322: Expecting a (. > > > > "(j)" is a list of variables to be PUT and it is expecting the > > parenthetical list of formats. > > > > 923 put x(3)= ; > > - > > 22 > > 76 > > ERROR 22-322: Syntax error, expecting one of the following: a name, > > arrayname, _ALL_, _CHARACTER_, _CHAR_, _NUMERIC_. > > Ian, > > A fine explanation, but why do the same rules for syntax checking do > not applying if the array index is not named, but merely used: > > 104 data _null_ ; > 105 array x x1-x5 (1 2 3 4 5) ; > 106 retain j 3 ; > 107 put x(j)= ; > 108 put x[j]= ; > 109 put x[3]= ; > 110 run ; > x3=3 > x3=3 > x3=3 > > Note that in this regard, there is no difference between J and _I_, > because with > > Array x (_i_) x1-x5 (1 2 3 4 5) ; > > the compiler will perceive x(_i_) as an attempt to write a list of > variables and flag the code, whilst with > > Array x x1-x5 (1 2 3 4 5) ; > > it will perceive x(_i_) as an array element to be written and give the > syntax a pass? > > The old documentation (V5, the only one available for the implicitly > subscripted arrays) mentions absolutely no behavioral difference > between _I_ named and _I_ implied, except that the implied _I_ is > auto-dropped. > > Now under which condition does SAS indeed look at X(J) as an attempt > to write a variable list rather than an array element? We all know: > When the array has not been defined prior to the reference AND > parentheses, rather than brackets, are used: > > 241 data _null_ ; > 242 j = 1 ; put x(j)= ; > - > 79 > 76 > ERROR 79-322: Expecting a (. > 243 run ; > > 244 data _null_ ; > 245 put x(1)= ; > - > 22 > 76 > ERROR 22-322: Syntax error, expecting one of the following: a name, > arrayname, _ALL_, _CHARACTER_, > _CHAR_, _NUMERIC_. > 246 run ; > > Which is the behavior fully consistent with what you go on to say: > > > You cannot PUT number literals in a list of variables (See above.) > > Of course, if under the same conditions brackets are used, the > references are perceived as array references: > > 247 data _null_ ; > 248 j = 1 ; put x[j]= ; > ERROR: Undeclared array referenced: x. > 249 run ; > > 250 data _null_ ; > 251 put x[1]= ; > ERROR: Undeclared array referenced: x. > 252 run ; > > Again, in agreement with your comment > > > The [] notation is seen as an illegal for the reason stated, which > > shows the superiority of brackets over parentheses in array > notation. > > > > The rest of the behavior is consistent with the original posting. > > I think not. In the original posting, > > 291 data _null_ ; > 292 retain x1 - x5 1 ; > 293 array x x1-x5 ; > 294 put x[3]= ; > 295 _i_ = 4 ; > 296 put x= ; > 297 run ; > x3=1 > x4=1 > > compiles and runs just fine. But name the index _I_ in the array > declaration, and the step bombs exactly as if the array has not been > declared: > > 298 data _null_ ; > 299 retain x1 - x5 1 ; > 300 array x (_i_) x1-x5 ; > 301 put x[3]= ; > ERROR: Mixing of implicit and explicit array subscripting is not > allowed. > 302 _i_ = 4 ; > 303 put x= ; > 304 run ; > > 305 data _null_ ; > 306 retain x1 - x5 1 ; > 307 array x (_i_) x1-x5 ; > 308 put x(3)= ; > - > 22 > 76 > ERROR 22-322: Syntax error, expecting one of the following: a name, > arrayname, _ALL_, _CHARACTER_, > _CHAR_, _NUMERIC_. > 309 _i_ = 4 ; > 310 put x= ; > 311 run ; > > Thus, the question remains: Why does naming an index on the ARRAY > statement make the SAS compiler think the array has not been declared, > while leaving the index implied leads to no such behavior? The only > distinction between the named and implied indices the SAS V5 > documentation (the only one available for the topic being discussed) > mentions is that the unnamed _I_ is auto-dropped, whilst the named _I_ > is not - which is what indeed happens. But there is no indication why > the compiler would react to the two statements > > Array a a1-a3 ; > Array a (_i_) a1-a3 ; > > so drastically differently. > > Kind regards, > ===================== > Paul M. Dorfman > Jacksonville, FL > ===================== > > > > > > -----Original Message----- > > From: Paul Dorfman [mailto:paul_dorfman@hotmail.com] > > Sent: Wednesday, August 13, 2003 6:24 PM > > To: Ian Whitlock; SAS-L@LISTSERV.UGA.EDU > > Subject: Re: Twilight Zone: Array Implict or Explicit > > > > > > Ian, > > > > The behavior becomes more bizarre when the implicit subscript is > > *named*. While this > > > > 789 data _null_ ; > > 790 array x x1-x5 (1 2 3 4 5) ; > > 791 retain j 3 ; > > 792 put x(j)= ; > > 793 run ; > > x3=3 > > > > compiles and runs fine, this > > > > 794 data _null_ ; > > 795 array x (j) x1-x5 (1 2 3 4 5) ; > > 796 retain j 3 ; > > > > > > > > ERROR 76-322: Syntax error, statement will be ignored. > > > > 798 run ; > > > > produces a bizarre syntax error which the compiler sees, but the > > programmer does not. An attempt to print a hard-coded array > reference > > looks even more > > gross: > > > > 921 data _null_ ; > > 922 array x (j) x1-x5 (1 2 3 4 5) ; > > 923 put x(3)= ; > > - > > 22 > > 76 > > ERROR 22-322: Syntax error, expecting one of the following: a name, > > arrayname, _ALL_, _CHARACTER_, _CHAR_, _NUMERIC_. ERROR > 76-322: Syntax > > error, statement will be ignored. > > > > 924 run ; > > > > And the fix, which is to use square brackets [J] instead of the > > parentheses > > (J) in the PUT statement is equally odd, to say nothing of the fact > > that with reference to the ARRAY statement, it is exactly in > > reverse (i.e. (J) is > > > > OK, but [J] will produce a syntax error). > > > > 799 data _null_ ; > > 800 array x (j) x1-x5 (1 2 3 4 5) ; > > 801 retain j 3 ; > > 802 put x[j]= ; > > ERROR: Mixing of implicit and explicit array subscripting is not > > allowed. 803 run ; > > > > Of course now we get the compiler missive indicating that > using of the > > explicitly named index (J) for the array is viewed as an > accomplished > > attempt at implicit subscribing. This step seems to confirm it: > > > > 912 data _null_ ; > > 913 array x (j) x1-x5 j (1 2 3 4 5 3) ; > > 914 put x= ; > > 915 run ; > > x3=3 > > > > For these reasons, I, while admitting to using implicitly > subscripted > > arrays > > > > relatively widely, avoid explicitly named index variables > altogether. > > When a > > > > behavior is inexplicable (like syntax errors above, and I > bet SI will > > not spend a dime to fix them), it is better to stay away from its > > likely triggers. > > > > By the way, PUT and INPUT (I have tried it, too) statements (not > > functions) seem to be the only constructs where an explicitly > > subsripted array reference does not tell the compiler that it has > > occurred, and hence does not flag the nearest subsequent implicit > > reference. In fact, the circumstances under which it applies, are > > even more limited, because whilst > > the compiler overlooks the explicit subscription in the > > variable being > > printed, it reacts harshly when the same is used as a pointer > > control value: > > > > 988 data _null_ ; > > 989 array x x1-x5 _i_ (1 2 3 4 5 3) ; > > 990 put x[3] '*** Test ***' ; > > 991 put x= ; > > 992 run ; > > 3 *** Test *** > > x3=3 > > > > 993 data _null_ ; > > 994 array x x1-x5 _i_ (1 2 3 4 5 3) ; > > 995 put @ (x[3]) '*** Test ***' ; > > 996 run ; > > *** Test *** > > > > 997 data _null_ ; > > 998 array x x1-x5 _i_ (1 2 3 4 5 3) ; > > 999 put @ (x[3]) '*** Test ***' ; > > 1000 put x = ; > > ERROR: Mixing of implicit and explicit array subscripting is not > > allowed. 1001 run ; > > > > Kind regards, > > ================== > > Paul M. Dorfman > > Jacksonville, FL > > ================== > > > > >From: Ian Whitlock <WHITLOI1@WESTAT.COM> > > >Reply-To: Ian Whitlock <WHITLOI1@WESTAT.COM> > > >To: SAS-L@LISTSERV.UGA.EDU > > >Subject: Twilight Zone: Array Implict or Explicit > > >Date: Wed, 13 Aug 2003 14:11:00 -0400 > > > > > >Mike Rhoads and I had an interesting conversation this > > morning when he > > >asked, "How and at what point does SAS determine whether > an array is > > >implicit or explicit?" We were both somewhat shocked to > find it is > > >sort like a quantum wave that doesn't collapse until you > > observe it. > > >However, the collapsing is not quite symetric. > > > > > >1 data _null_ ; > > >2 retain x1 - x5 1 ; > > >3 array x x1-x5 ; > > >4 put x[3]= ; > > >5 _i_ = 4 ; > > >6 put x= ; > > >7 run ; > > > > > >x3=1 > > >x4=1 > > >NOTE: DATA statement used: > > > real time 0.64 seconds > > > cpu time 0.02 seconds > > > > > > > > >8 data _null_ ; > > >9 retain x1 - x5 1 ; > > >10 array x x1-x5 ; > > >11 _i_ = 4 ; > > >12 put x= ; > > >13 put x[3]= ; > > >ERROR: Mixing of implicit and explicit array subscripting is > > not allowed. > > >14 run ; > > > > > >NOTE: The SAS System stopped processing this step because > of errors. > > > > > >This shows that it is a compile time activity: > > > > > >39 data _null_ ; > > >40 retain x1 - x5 1 ; > > >41 array x x1-x5 ; > > >42 do _i_ = 1 to 5 ; > > >43 put x[_i_]= ; > > >44 put x= ; > > >45 end ; > > >46 run ; > > > > > >x1=1 > > >x1=1 > > >x2=1 > > >x2=1 > > >x3=1 > > >x3=1 > > >x4=1 > > >x4=1 > > >x5=1 > > >x5=1 > > >NOTE: DATA statement used: > > > real time 0.08 seconds > > > cpu time 0.02 seconds > > > > > >However, this shows that it depends on what is compiled and that > > >symmetry is almost preserved, thus explaining our shock. > > > > > >85 data _null_ ; > > >86 retain x1 - x5 1 ; > > >87 array x x1-x5 ; > > >88 y = x[5] + 1 ; > > >89 _i_ = 5 ; > > >90 put x= ; > > >ERROR: Mixing of implicit and explicit array subscripting is > > not allowed. > > >91 run ; > > > > > >IanWhitlock@westat.com > > > > _________________________________________________________________ > > MSN 8 with e-mail virus protection service: 2 months FREE* > > http://join.msn.com/?page=features/virus > > >


Back to: Top of message | Previous page | Main SAS-L page