[comp.lang.ada] Just an opinion

blackye@cisunx.UUCP (Andrea Cocito) (12/04/88)

Well, this is my opinion about the overloading of the ':=' "operator".
First:
	The reason why ada doesn't allow a

		procedure ":="(LVAL: out MYTYPE; RVAL: in MYTYPE) is ...
or
		procedure ":="(LVAL: in out MYTYPE; RVAL: in MYTYPE) is ...

	is that none of the two could ever work.
	The first one would not let the procedure know the 'old' value
        of the variable beeing assigned, while the second would crash
        (CONSTRAINT_ERROR) for an uninitialized variable.

The problem is that ada does not allow a 'var' parameter, or any other
way to pass a parameter 'by reference', in out parameters are COPYED into
the activation record of the called procedure and COPYED back into the
variable after the procedure returns:

with text_io; use text_io;
procedure ONE is
package iio is new integer_io(INTEGER); use iio;
X: INTEGER;
    procedure TWO(A: in out INTEGER) is
    begin
	A := A + 1;
	PUT(X);
	NEW_LINE;
    end TWO;
begin
   X := 1;
   TWO(X);
end ONE;

Definitively prints '1'.

If ada allowed (and it should be this way, and not only for this reason.)
a 'var' (or, if we really want it to be "DIFFERENT" from pascal a 'ref')
parameter passing mode it would make sense something like:

procedure ":="(LVAL: var MYTYPE; RVAL: in MYTYPE) is...

Point two:

I think that the 'generic' create some confusion about the static
data area, and this because they are trated in a way different from the
non-generic units:
If i declare

package X is
Y : integer;
....
end X;

..and..

generic .....
package W is
Z : INTEGER;
....
end W;

When i actually 'use' this two packages i will have that different
instantiations of X will always use the same Y, while different instantiations
of W will use different Z's.
I can 'fool' the language including W into another non-generic package but i
actually have no other way to have different copyes of Y than writing the
package as:
generic package X is...

But it doesn't make much sense, because i am out of the pourpose of a
'generic' feature (it should be a 'template' that allows be to apply the
same algorithms to different data structures) and moreover i am basically
creating a data structure (Isn't it an OBJECT ????), but ada doesn't
allow me to handle this as an object (I can not have an ARRAY of PACKAGES).

I think it would be much better something like:

[ generic
  generic_parameters
  [ private
    private_part
    [ static
      static_part_g      ## Objects common to all the instantiations with the
      ]                     SAME actual parameters for the instantiation.
    ]
  ]
package type NAME is     ## Or any compilation unit.
local_part               ## Objects that belong to EACH instantiation
                         ## of the unit.
[ static
  static_part_p          ## Objects common to all the instantiations
  ]                      ## (this is the TRUE GLOBAL data area)
[ begin
  instr_list ]
end NAME

Obviously in the objects declared in static_part_p should not be allowed any
'reference' to the generic parameters (could it be different ?), and all the
packages (generic or non generic) should be instantiated with the same form
of object
declaration... i mean a OBJECT declaration because a package should be a type
(As it is for tasks).

At this point: why not make it simpler also for tasks and abolish the
task X is.., forcing the user to use always task type, (it would be
just a few letters longer, but it would certainly be more uniform.).


---
Non Generic Disclaimer: Excuse me if I say something really stupid, i'm only
a young student, Excuse me if you don't understand what i say, i don't speak
English well, If you don't agree with my opinions let me know, i'll be happy
to listen yours, but if you think that you don't need to listen at mines
becouse you have a very long list of degrees and a Dr or Ing prefix on your
name... and i am just a student..... well, the common rules of education
keep me from telling you what i think of you.

Andrea Cocito.

blackye@unix.cis.pittsburgh.edu (Andrea Cocito)
bkh@uxp.tecnopolis.bri.pri [Not reachable from USA].