[Date Prev][Date Next][Thread Prev][Thread Next]
[Author Index]
[Date Index]
[Thread Index]
[SQR-USERS Info]
[SQRUG Home Page]
Re: SQR Create Array
- Subject: Re: SQR Create Array
- From: Mark Johnson <markjo@netcom.com>
- Date: Fri, 9 Jun 1995 11:53:01 -0600
Scott,
I think that I see your problem. It is probably best to either warn
your programmers about this, or enhance your conventions to take this into
account. Putting create-array statements in the setup section is a good
idea. Alternatively, you could have procedures that create arrays have
their procedure names start with 'aa_' (announce array) or have the names
start with an underscore. Although there always seems to be resistance to
changing conventions, it is usually easier than redesigning a compiler.
Hope this helps.
Mark
On Fri, 9 Jun 1995, Scott May - SICAS Center - SUNY Oneonta wrote:
> Hello all,
>
> Another Programmer here fell into a common pitfall with arrays
> yesterday, and while I was thinking about it I thought I'd pose this as
> a possible enhancement to SQR at some future date, as well as a technical
> note.
>
> Our Programming Standards require that all procedures are alphabetized.
> A program starts with the Setup and Report Sections and then is followed by
> the procedures in alphabetical order.
>
> If I have an Access Array procedure and a Create Array procedure
> in alphabetical order, the array access statement in the Access Array
> procedure will generate an error stating that the array has not been created.
> The logical calling of these procedures is correct though. This occurs
> because SQR did not physically encounter the CREATE ARRAY before the GET or PUT
> statement.
>
> I make it a standard practice to define all arrays in either the REPORT
> section, or the Setup section since they are the first two sections in our
> programs, and arrays are most usually global in nature. I understand compiler
> design enough to know why this occurs, and that there is not a quick
> modification to resolve this either. The error can cause confusion if a
> programmer is not aware of this.
>
>
> Thanks,
> Scott May
> ****************************************************************
> * Programmer / Analyst | State University of New York *
> * SICAS Center | SUCO *
> * | Lee Hall *
> * Internet: maysa@oneonta.edu | Oneonta, NY 13820 *
> ****************************************************************
>
>