Type mess in Ada standard library

Type mess in Ada standard library

[Markus Kuhn]

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

Re: Type mess in Ada standard library

[Michael F. Yoder]

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

Re: Type mess in Ada standard library

[Robert Dewar]

In article <7n1uu4$so8$1@pegasus.csx.cam.ac.uk>,
  mgk25@cl.cam.ac.uk (Markus Kuhn) wrote:

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

First: this story is badly distorted. The design team was
unanimous in supporting derived types, it was the reviewers
group who questioned this decision.

Second: it is clear that in fact derived types have played a
crucial role, particularly in that they provided the basis
of the very nice OOP design of Ada 95.

Speaking as one of those reviewers who argued for eliminating
derived types early on, it is clear that it was a long term
benefit to keep this feature in the language.

By the way, derived types have nothing AT ALL to do with basic
strong typing, those are orthogonal issues. What Marcus is more
concerned with here is structural vs named types. For example
if we write:

  type x1 is access string;
  type x2 is access string;

then types x1 and x2 are distinct, but this has nothing at all
to do with derived types, so actually Marcus' comments on
derived types are somewhat of a red herring.

It is definitely the case that it is occasionally annoying to
have to create named access types, when what you really want
is the anonymous access type created by an access parameter.

Consider now the choice between

  function (x : access integer) ...
  function (x : integer_access) ...

The first is often attractive in bindings, but does not permit
passing null. The second is often a pain in bindings because
it forces local definitions of unneeded access types.

I would have liked to see an attribute, call it for now

  typ'Anonymous_Access

that created an anonymous access type to "typ". Indeed we
have discussed adding such an attribute to GNAT, particularly
for helping to solve the binding generation problem, where
such access types are common.

The original version of the bindings produced by Intermetrics
used access parameters everywhere, but turned out to depend on
a bug in a very early version of GNAT of not checking for null.
Once this bug was fixed, named access types had to be introduced
and the clarity and usability of the bindings suffered.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Type mess in Ada standard library

[Markus Kuhn]

Robert Dewar <robert_dewar@my-deja.com> writes:
|> It is definitely the case that it is occasionally annoying to
|> have to create named access types, when what you really want
|> is the anonymous access type created by an access parameter.
[...]
|> I would have liked to see an attribute, call it for now
|> 
|>   typ'Anonymous_Access
|> 
|> that created an anonymous access type to "typ". Indeed we
|> have discussed adding such an attribute to GNAT, particularly
|> for helping to solve the binding generation problem, where
|> such access types are common.

That sounds like a very good idea to me, and adding this in GNAT
would certainly be a valuable contribution. (It would be even nicer
if this were not a product-specific proprietary extension of the
language but part of the core language.)

Would it at the same time also be possible to add anonymous arrays?

  typ'Array(0..255,0..255)  -- anonymous 64k 2D array of typ
  typ'Array(<>,<>,<>)       -- any 3D array of typ

or something like that, which wherever they are used lead to identical
types iff the parameters are identical.

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

Re: Type mess in Ada standard library

[Robert Dewar]

In article <7n41v3$j6$1@pegasus.csx.cam.ac.uk>,
  mgk25@cl.cam.ac.uk (Markus Kuhn) wrote:
> Robert Dewar <robert_dewar@my-deja.com> writes:
> |> I would have liked to see an attribute, call it for now
> |>
> |>   typ'Anonymous_Access

Just to be clear I would ONLY allow this in subprogram formals,
and I would be quite happy to restrict it to those which had
foreign conventions, otherwise I am afraid it would be horribly
overused.

> That sounds like a very good idea to me, and adding this in
> GNAT would certainly be a valuable contribution.

I am not so sure, I am afraid it would be misused

> Would it at the same time also be possible to add anonymous
> arrays?
>
>   typ'Array(0..255,0..255)  -- anonymous 64k 2D array of typ
>   typ'Array(<>,<>,<>)       -- any 3D array of typ

In fact it is *exactly* this question that makes me think that
it is a bad idea to introduce the anonymous access type. If
people simply think of this as a way to weaken typing (as in
the above array proposal), rather than as a way to solve a
particular problem in genericity at the interfacing level, I
am afraid that such features can do more harm than good.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Type mess in Ada standard library

[Aidan Skinner]

On 21 Jul 1999 08:56:03 GMT, Markus Kuhn <mgk25@cl.cam.ac.uk> wrote:

>or something like that, which wherever they are used lead to identical
>types iff the parameters are identical.

While were on the subject of adding stuff, could we have something
that would auto-generate an explicit type-conversion for structually
equivalent types?

Eg.

  declare

  type Foo is record
     X : integer;
     Y : Character;
  end record;

  type Bar is record
     X : integer;
     Y : Character;
  end record;

  Foo1 : Foo;
  Bar1 : Bar;

  begin
     Foo1 := Foo (Bar1);
  end;

- Aidan (oh, and I'd like a flake in that as well)
--
http://www.skinner.demon.co.uk/aidan/
How much can could ICANN can if ICANN could can-can?

Re: Type mess in Ada standard library

[Bill Findlay]

In article <7n41v3$j6$1@pegasus.csx.cam.ac.uk>,
mgk25@cl.cam.ac.uk (Markus Kuhn) wrote:

> 
> Would it at the same time also be possible to add anonymous arrays?
> 
>   typ'Array(0..255,0..255)  -- anonymous 64k 2D array of typ
>   typ'Array(<>,<>,<>)       -- any 3D array of typ
> 
> or something like that, which wherever they are used lead to identical
> types iff the parameters are identical.

This is beginning to look somewhat like (BS/ISO) Standard Pascal
conformant array parameters!

When I posted on Pascal's type relations I restrained myself
from a presentation of the relationship of "conformability"
between an array type and a conformant array schema.

Essentially, conformant array parameters provide anonymous
array parameter types, with syntax that smuggles the array
'first and 'last attributes into Pascal.

They were motivated by the problem of binding to libraries of
array-intensive routines (especially, NAG) in the context
of Pascal's lack of unconstrained array types; but they also
greatly alleviated the difficulty of writing reusable string
handling subprograms in Standard Pascal.
(I.e. they made it possible to write reusable string handling!)

Example:

procedure sayHello (name : packed array [low..high : Integer] of Char);
  var i : Integer;
begin
   write('Hello: ');
  for i := low to high do
    write(name[i]);
end;
...
sayHello('Bill');
sayHello('sailor');

Excuse any Ada-isms in the syntax - it's a long time since I last
wrote Pascal code.  8-)

The introduction of conformant array parameters was the only
bit of new language design that the authors of BS Standard Pascal
indulged in; but we did so at the specific request of Niklaus Wirth
and Tony Hoare, so we felt ourselves righteously justified!

-- 
Bill Findlay
Department of Computing Science
The University of Glasgow

Re: Type mess in Ada standard library

[Bill Findlay]

In article <7n5cp9$89b$1@nnrp1.deja.com>,
Robert Dewar <robert_dewar@my-deja.com> wrote:

> > |>   typ'Anonymous_Access
> 
> Just to be clear I would ONLY allow this in subprogram formals,
> and I would be quite happy to restrict it to those which had
> foreign conventions, otherwise I am afraid it would be horribly
> overused.
> 
...
> > Would it at the same time also be possible to add anonymous
> > arrays?
> >
> >   typ'Array(0..255,0..255)  -- anonymous 64k 2D array of typ
> >   typ'Array(<>,<>,<>)       -- any 3D array of typ
> 
> In fact it is *exactly* this question that makes me think that
> it is a bad idea to introduce the anonymous access type. If
> people simply think of this as a way to weaken typing (as in
> the above array proposal), rather than as a way to solve a
> particular problem in genericity at the interfacing level, I
> am afraid that such features can do more harm than good.
> 

I would much rather see Markus' anonymous array parameters in Ada than
the existing anonymous array types, which are a pitfall for beginners
yet add no new functionality.

The Standard Pascal conformant array feature does indeed apply
only at the level of (subprogram) interfacing, although complicated
proposals to apply the idea more broadly were eventually included
in Extended Pascal, essentially to provide Ada's unconstrained
array type functionality.

-- 
Bill Findlay
Department of Computing Science
The University of Glasgow

Re: Type mess in Ada standard library

[Stanley R. Allen]

Robert Dewar wrote:
> 
> In article <7n41v3$j6$1@pegasus.csx.cam.ac.uk>,
>   mgk25@cl.cam.ac.uk (Markus Kuhn) wrote:
> 
> > Would it at the same time also be possible to add anonymous
> > arrays?
> >
> >   typ'Array(0..255,0..255)  -- anonymous 64k 2D array of typ
> >   typ'Array(<>,<>,<>)       -- any 3D array of typ
> 
> In fact it is *exactly* this question that makes me think that
> it is a bad idea to introduce the anonymous access type. If
> people simply think of this as a way to weaken typing (as in
> the above array proposal), rather than as a way to solve a
> particular problem in genericity at the interfacing level, I
> am afraid that such features can do more harm than good.
> 

History repeats itself.  I remember when the revision process
started for Ada 9X, at the beginning there were a great many
language proposals which effectively ignored Ada's basic
foundational concepts.  There were articles in Ada Letters that
shocked me, the suggestions  were so wild.  On the old INFO-ADA
list (twin sister to CLA) there was always someone popping off
with an impromptu language change.

I was relieved when I went to a WAdaS conference around that
time and heard a panel of authorities involved in the Ada 9X
process.  One panelist made reference to these kinds of
suggestions by making an analogy: that the suggestions he had
heard reminded him of a group of people walking through a
cathedral and discussing modifications, and they come upon
one of the supporting pillars of the structure.  One of them
says "This pillar is sort of inconveniently placed -- let's
move it to a different part of the cathedral".

-- 
Stanley Allen
mailto:s_allen@hso.link.com

P.S Does anyone know how to get access to the archives of
the old INFO-ADA list?

Re: Type mess in Ada standard library

[Tucker Taft]

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

Well, to answer this question narrowly:  These Stream_Access types
are *only* used as the result type of the "Stream" function, which
is designed for passing directly into another subprogram like
T'Input, T'Output, etc.  So at least in this particular case,
there is almost no need to define any variables of the type
Stream_Access (and in fact, it is probably unwise, since the
lifetime of the access values produced is tied to the lifetime
of the File type).

I appreciate your larger concern, but I think in this
case the use of a local Stream_Access type is appropriate.
Perhaps a "NOTE" to indicate the intended use of values of
Stream_Access type might have alleviated your concern.

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

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA