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,
	MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,eda0a7cd6069ee4
X-Google-Attributes: gid103376,public
From: Robert Dewar <robert_dewar@my-deja.com>
Subject: Re: Type mess in Ada standard library
Date: 1999/07/21
Message-ID: <7n32tt$cio$1@nnrp1.deja.com>#1/1
X-Deja-AN: 503314949
References: <7n1uu4$so8$1@pegasus.csx.cam.ac.uk>
X-Http-Proxy: 1.0 x32.deja.com:80 (Squid/1.1.22) for client 205.232.38.14
Organization: Deja.com - Share what you know. Learn what you don't.
X-Article-Creation-Date: Wed Jul 21 00:06:29 1999 GMT
X-MyDeja-Info: XMYDJUIDrobert_dewar
Newsgroups: comp.lang.ada
X-Http-User-Agent: Mozilla/4.04 [en] (OS/2; I)
Date: 1999-07-21T00:00:00+00:00
List-Id: <comp.lang.ada>

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.