Ada programmer errors (an update)

Ada programmer errors (an update)

[John Goodenough]

Last Fall, I asked people to send me examples of errors they make (or have
seen made) when writing Ada programs.  I received a modest response which I
have recently augmented by perusing some vendor problem report files to find
those reports where the compiler turned out to be right.  The review of vendor
problem reports has about doubled the number of error examples to 70-80.  

I'm still collecting errors.  Send in your contribution by net mail or snail
mail (even handwritten is okay).  Maybe you could send a memo to some of your
colleagues asking them to jot down one or two Ada programming errors that
stick in their mind, and send me the raw data.

I have found that Ada-related programming errors can be usefully classified as
follows:

        .  PERCEIVED NON-UNIFORMITIES in the language: exceptions to
           rules that are in the minds of programmers, e.g.,
    
                .  the precedence of unary minus is different from the
                   precedence of other unary operators (although the same
                   as the precedence of binary minus)

        .  NEW CONCEPTS: differences from previously used programming
           languages that cause confusion, e.g.,

                .  each type declaration declares a distinct type

        .  UNAVOIDABLE COMPLEXITIES: complex rules that trip up the
           everyday programmer, e.g.,

                .  rules for use of OTHERS in array aggregates

        .  BLUNDERS: mistakes that are easy to make even though the
           rules are clear, e.g., 

                .  inadvertent use of reserved words as in

                   type Direction is (Forward, Reverse, Up, Down, Left, Right);

        .  UNEXPECTED EFFECTS: unappreciated consequences of rules,
           leading to subtle bugs in programs, e.g.,

                .  effect of attempting to read the sequence 

                        13 16.2 

                   with GET instantiated for type INTEGER.

(This last category contains some of the most interesting errors.)

A document containing the errors using this classification scheme will be
prepared in a few months.  In the meantime, I'm including in this message the
topic lines for the errors currently in the collection.  If you want to see the
full set of errors right away (about 42K characters), send me a net message.

			    Ada Programmer Errors

        0.0       different uses of =>
        0.0       variables set but not referenced, and vice versa
        2.3       illegal use of underscore
        2.5       one character string literals or character literals
        2.9       inadvertent use of reserved words
        3.2       anonymous array types
        3.2.2     Using non-universal constants in number decls.
        3.3.1     types vs. subtypes; strong typing
        3.3.1     Using base type name in type definition
        3.3.1(4)  type declarations declare distinct types
        3.5.1     'FIRST of enumeration literal has position number zero
        3.5.5     'RANGE and 'LENGTH not defined for scalar types
        3.5.5     VAL attribute does not depend on rep. clause
        3.5.9     Failure to include range in fixed point declaration
        3.5.9     Fixed point subtype declarations
        3.6       No partially constrained arrays
        3.6.2     no numeric operators for array types
        3.6.3     Length of actual string parameter arguments
        3.6.3(1)  the index subtype for STRING is Integer
        3.7       No anonymous array types for record components
        3.7.1     NUMERIC_ERROR for unconstrained record objects
        3.8.1     Using an incomplete type prematurely
        3.9(2)    basic declarations not allowed after bodies
        3.9(6)    Activating a task whose body has not been elaborated
        4.0.3     Using Pointers and .all
        4.1.3     Using .all to access whole records
        4.3(4)    aggregates with only one component
        4.3.2     Rules for using others choice
        4.4       Can't parenthesize range
        4.5.4     precedence of unary minus
        4.9(8)    Size of a record is not static
        5.2       Failure to use aggregates in assignments
        5.2.1(2)  No sliding of array components in record aggregates
        5.4(2)    not all choices can be parenthesized
        5.4(4)    Use of RANGE attribute in loops and case statements
        6.2       Slices used as actual parameters
        6.2(2)    Incorrect use of formal parameter modes
        6.2(5)    Assignment to component designated by OUT parameter
        6.3       ; instead of IS in subprogram bodies
        6.3(2)    Bodies that use IS rather than semicolon
        6.3.1(5)  can't omit IN in parameter decl if it is present in body
        6.3.2(4)  dependence on body due to INLINE
        6.6(1)    Parameter names not considered in overloaded declarations
        8.3       visibility rules for operators
        8.3       visibility of operators
        8.3(15)   Object declaration hides outer procedure declaration
        8.3(18)   Need a use clause to get visibility of operators
        8.4(5)    Conflict with a name declared in Standard
        8.4(6)    Effect of USE on generic subprograms
        8.4(6)    Use clause and renamed exceptions
        8.5       renaming task entries
        8.5       ignoring constraints in renaming
        9.4       Nested task termination and leaving block
        9.4(13)   Termination of library tasks
        9.6       delay 2.5*minutes is illegal
        9.6(1)    Delay statments can be used in the main program
        9.7.1     evaluation of guards
        10.1(6)   recompiling a library subprogram body
        10.1.1    A with clause is not like an Include
        10.1.1    confusion of with and use
        10.2      Spelling SEPARATE correctly
        10.2(5)   Overloaded subunits are illegal
        10.2(5)   Subunits cannot be operators
        10.5(3)   Failure to use pragma ELABORATE for generic units
        11.4.2    Handling exceptions raised in declarations
        12.1      No out mode for generic formal objects
        12.1      no overloaded generic units
        14.3      I/O calls in tasks
        14.3      Associating two file variables with a terminal
        14.3.5(3) PUT at the end of the program
        14.3.7(6) Use of Integer GET to read real literals
        14.3.9(6) Failing to advance after DATA_ERROR for GET

John B. Goodenough                           goodenou@wanginst        (CSNET)
Wang Institute of Graduate Studies           decvax!wanginst!goodenou (UUCP)
Tyng Road, Tyngsboro, MA 01879               Goodenough@ISI           (ARPA)
(At Wang Institute until 6/1/86)             617-649-9731

Ada errors with =>

[Frank Adams]

John Goodenough has noted in his survey that the use of the => operator
tends to cause problems for those who are new to Ada.  This is accompanied
by a perception that it is used differently in different contexts.  I
believe this perception is incorrect; the use of the symbol is completely
uniform.  In general, its use in the form <name> => <value>.

Why, then, do people have so much trouble with it?  (And I had trouble with
it, too, when I first encountered it.)  The answer, I maintain, is because
the symbol looks like an arrow, and that arrow points in the wrong direction.

An arrow looks like an assignment, and we assign values to names, not vice
versa.

Since <= is not available, I think a direction neutral symbol, perhaps ==,
would have been a better choice.  It is perhaps too late to make this change
now; on the other hand, perhaps later versions of the language could support
it as an alternative.

Frank Adams                           ihpn4!philabs!pwa-b!mmintl!franka
Multimate International    52 Oakland Ave North    E. Hartford, CT 06108

Re: Ada errors with =>

[Christopher Byrnes]

  I'm not sure that the use of a `==' operator in place of the `=>' is
going to solve the problem.  As a "C" language programmer, I might
recognize the `==' operator as the logical equality operator.  I'm not sure
what other languages have used `==' for.  Ada's use of `=>' (for named
parameter association, etc.) is sufficiently different from what most other
computer languages provide that it deserves a "different" operator.  Once a
programmer gets use to the concept, they shouldn't mind which way the
"arrow" is pointing.
					Christopher Byrnes
					The MITRE Corporation
					Burlington Road
					M. S. A425
					Bedford, Mass. 01730

					cb@Mitre-Bedford.ARPA
					...decvax!linus!bccvax!cb.UUCP