From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,eda0a7cd6069ee4,start
X-Google-Attributes: gid103376,public
From: mgk25@cl.cam.ac.uk (Markus Kuhn)
Subject: Type mess in Ada standard library
Date: 1999/07/20
Message-ID: <7n1uu4$so8$1@pegasus.csx.cam.ac.uk>#1/1
X-Deja-AN: 503128204
Organization: U of Cambridge Computer Lab, UK
Newsgroups: comp.lang.ada
Date: 1999-07-20T00:00:00+00:00
List-Id: <comp.lang.ada>

Why do the packages

  Ada.Streams.Stream_IO

and

  Ada.Text_IO.Text_Streams

both have to define their own identical but incompatible

  type Stream_Access is access all Streams.Root_Stream_Type'Class;

???

This looks like a complete mess to me. If I use both packages (and
it is certainly not unreasonable to do so!), I have two different types
for exactly the same purpose. This is a classical example of the
needless type inflation under which so many Ada libraries suffer,
just because frequently required types are not defined in the
base packages into which they really should belong, and because
Ada forces library writers to create new types each time something
isn't already available in the standard library. Stream_Access
very clearly should have been defined in Ada.Streams, which is
anyway used by both the above packages.

Did I just missunderstand something here, or is the Ada standard
library really as badly designed at some places as I get the
impression?

This brings me to a more general question:

I have heard the story that derived types (probably the underlying
reason for all these problems) were introduced against the vote of
all other Ada83 design team members by Jean Ichbiah alone. I think
more and more that this was a very big mistake. It causes a lot of headaches
that never show up in other languages without derived types if one
wants to avoid ugly type conversions. The problem is not the existance
of derived types, but that Ada forces programmers to create new incompatible
types at much too many places, e.g. each time you create an access or
array type of something.

For example, some package A defines a type T, and two other independently
developed packages B and C both define arrays over T. Then there is
no way for B and C to come up with a common type for these arrays over
T, unless they know about each other a priory. This severely hinders
code reusability, because programmers who want to move arrays of
T between B and C now constantly have to copy these around, even
though the machine representation is identical and there is no
technical reason at all for doing this copying.

Again, did I just missunderstans something, or is it really that bad?
Is it really not possible to create in a compatible (= not requiring
conversions) way pointers to and arrays of some type T in Ada?
In C, if I create a (T *) type here and a (T *) type there, then they
are automatically the same time and can be assigned to each other without
any problems. How do I do this with pointers and arrays in Ada?

Markus

-- 
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org,  WWW: <http://www.cl.cam.ac.uk/~mgk25/>