Re: Future Ada language revisions?

[mfb@mbunix.mitre.org (Michael F Brenner)]

On the topic of IN OUT parameters for Ada functions:
  > We all lack perspective, and I probably lack more than most. However, when
  > I find myself using access parameters (and then aliased variables :-) to
  > work around this restriction, I'm forced to ask myself if the cure isn't
  > worse than the disease (side effecting functions).

Using pointers and the Ada ALIASED keyword is only one way to alias variables.

However, IN OUT parameters have the same coupling effect (to alias
the variables through the parameter passing interface). The verb to alias
means to permit changes in one variable to effect the value of another.

Aliasing of any kind (including homonyms) encourages programmers to
insert bugs in their code and then provides a path in the variable 
name space through which those bugs can propogate to other parts of the
code.
 
We should therefore become more aware of what language features
cause aliasing to occur in address space or in name space, because
of the software maintenance implications of this aliasing (that is,
because aliasing provides bug propogation paths). To become more
aware, here is a list of the Ada constructs (other than ALIASED) which
provide a form of aliasing:
    overloaded variables such as RENAMES or equivalences or commons
    homonyms such as overloaded enumeration elements or array elements
    polymorphism or objects with changeable discriminants or tags
    external objects shared with other languages (e.g. pragma INTERFACE)
    parameters passed by reference (such as IN OUT)
    unchecked_conversion
    pointers or access type variables
    forcing the use of access variables to get things off the stack
    non-limited-private types
    re-use of variables for multiple assignments
    use of protocols like temporary variables or intermediate files
    non-limited-private-types

Mike Brenner   mikeb@mitre.org