Re: Type mess in Ada standard library

["Michael F. Yoder" <yoder@decada.zko.dec.com>]

Markus Kuhn wrote:
> 
> 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;
> 
> ???

They don't have to, but it is a good idea to do so.

> 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.

They are only "for the same purpose" if you take a machine-oriented view
of things rather than a problem-oriented one.  The latter is more
appropriate here.  It should be clear that the ability to distinguish a
text-only stream from a general one via strong typing is desirable.  If
you really need to interconvert, you can use P.all'Access.  If this is
unaesthetic, it doesn't bother me, because needing to interconvert
suggests there is a misdesign somewhere.

> 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.

The creation of new types is in almost every case a good thing, not a
bad one.  This is what strong typing is all about.  Indeed, strong
typing is nearly the only technique in computer science that deserves to
be called a magic bullet.  I'm not talking about aesthetics; I'm
measuring its value entirely in money, or, if you prefer, labor hours
spent by programmers and testers.

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

I suspect you undervalue strong typing to a huge degree.  This is common
in the industry but less common in comp.lang.ada.  :-)

> 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.

I'm unwilling to condemn the other team members here, because I don't
know what my opinion would have been knowing only the information
available at the time.  However his judgment was unquestionably
vindicated in this case.

> 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.

I don't think this is so: you can use a type conversion on an 'out' or
'in out' parameter and a good compiler will pass by reference.  But
different arrays of T may need copying for at least three reasons: (1)
the strides may be different, as in packed vs. unpacked versions; (2) if
the index type is a "gappy" enumeration type with non-consecutive
representation values, two array types may use different indexing
methods; (3) a FORTRAN-style array may order elements differently.

> 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?

This aspect of C is a very major bug, not a feature.  Try this
experiment: examine available problem notesfiles of various projects and
roughly estimate the number of programmer hours lost due to weak typing
in (say) a month.  Multiply by your estimate of the number of projects
in existence, divided by the number of projects you examined, and then
multiply by 12 to get an estimate of the yearly cost to the industry of
weak typing.  All of that money and time could have been spent on
activities more productive than bug-hunting and bug-fixing.

--
----
Michael Yoder