Paul -- What you say, viz:
"Misusing "default" to describe the universal assignment can mislead the reader to believe that the construct merely defines a value to be used for members otherwise undefined." is absolutely true, but I would hazard a guess, based on my own 20+ years of rexx experience, that the vast majority of programmers only use, if they use at it at all, the construction x. = 'something' at the top of their programs, and then never change it. Is calling that a "default" strictly accurate? Of course not. But in the context of the original discussion, "does rexx support multi-dimensional arrays?" I think that to describe it otherwise in a list of additional features which might be of interest to a newcomer would be a severe case of TMI. BTW, Unless I've misunderstood your point, I'm not sure that your sample program demonstrates the language feature we're discussing. (x. = 'universal' perhaps?) i ------ Original Message ------ Received: Thu, 19 Mar 2009 06:55:22 AM COT From: Paul Gilmartin <[email protected]> To: [email protected] Subject: Re: Multi-dimensional arrays in REXX > On Thu, 19 Mar 2009 01:11:23 -0400, Gerhard Postpischil wrote: > > >Ian S. Worthington wrote: > >> I'm aware of the distinction, but have always felt that that's a fairly > >> reasonable working definition of "default", at least up until a reassignment. > > > >I suspect that he considers the language assignment of the > >upper-cased variable name to be the default, hence the distinction? > > > While that's true, it's the lesser concern. Misusing "default" > to describe the universal assignment can mislead the reader to > believe that the construct merely defines a value to be used > for members otherwise undefined. With this assumption, readers > of the following program: > > /* Rexx */ signal on novalue; /* > Universal assignment is not a "default value". > */ > trace R > > X.42 = 'specific ' > say symbol( 'X.42' ) value( 'X.42' ) > > X.42 = 'universal' > say symbol( 'X.42' ) value( 'X.42' ) > > drop X.42 > say symbol( 'X.42' ) value( 'X.42' ) > > .. may expect incorrect results from the second and/or third > "say" instructions. This is more likely for readers with > some programming experience, who are likely to make incorrect > and oversimplified assumptions about the implementation > mechanism. Even IBM developers have fallen victim: at one > point an attempt to optimize storage management caused Rexx > to give incorrect results for the third "say" instruction. > This appears to have been repaired by APAR. > > --gil > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
