Re: Ada2005

["Mark Lundquist" <mlundquist2@attbi.com>]

"Carsten Freining" <freining@informatik.uni-jena.de> wrote in message
news:3C1754BA.C4560423@informatik.uni-jena.de...
> Hello Peter,
>
> I think Ada95 needs a very urgent revision.
>
> 1. There are many things that have been overtaken by Ada83 and can be
> removed now. Since everybody knew it would be removed no new software
should
> rely on it.

Can you give more detail?  Which things?  I take it you mean more than just
the Annex J stuff -- its presence in an annex can't be giving anyone so much
trouble as to call for a "very urgent revision"...

Please elaborate... I'm sure many of us are interested.

>
> 2. There are many problems that have been created by Ada95.
>
> Best example is the object oriented part, because it is not possible to
have
> constants as components.

Why would you want to have a constant (in the Ada95 sense) as a component
(of a non-constant composite type)?

Perhaps you mean an immutable component, but Ada already has those
(discriminants).

> There are no real bindings between methods (or
> procedures) and the belonging class. It is just a package.

What's "just" about a package :-), and how is that not a "real" binding?
Generally, subprograms operating on a type and declared in the immediate
scope of the type are the primitive (heritable) operations, i.e. methods.
The method declarations are not textually included in the type definition
syntax, but how is that a problem?

You're never going to get Ada changed into a class-oriented language, if
that's what you're after.  There are just too many users who feel that
class-orientedness is a Bad Thing.  We believe in strong encapsulation, and
also in using the best tools for the job, including inheritance and
polymorphism whenever they are the best tool, but we don't like the
distorted perspective of class-orientation.

Here's an interesting thing to think about... Ada is a language that (a) is
lexically scoped, and (b) unifies encapsulation with namespace control,
where the namespace is hierarchial (public and private child packages).  So
ironically, Ada allows for tighter encapsulation than that provided by flat
class-oriented languages.  (It also allows for looser encapsulation, by
permitting object declarations in package specs, arguably a Bad Thing).

But adding class-orientation would add nothing to Ada, and IMO would
compromise its conceptual integrity.  The designers of Ada95 did the right
thing.

What other problems are created by Ada95?

>
> And there is still the fixed length String. I don't think it is
neccessary.
> It would be better to have only the bounded-length string. For downwards
> compatibility they both can still be available, but I think it is an
ancient
> thing to still have a fixed length String were only String with exactly
the
> same length can be assigned.

How would it help the language to do away with fixed-length strings?

String manipulation in Ada has a "functional" flavor that is hard for
beginners to comprehend right away, especially if they have been conditioned
by exposure to languages where "constant" entails "static".  But once you
get the hang of it, it's easy and elegant.

>
> These are only the examples coming to my mind reading, that Ada95 needs no
> revision. There are many more (it is just hard to put them together in a
> couple of minutes). We went through the rational and compared the stuff
> there with the Standard and we found many things, where ada 95 has been
> behind all other techniques right from the start.

Did you write a paper or something?  Can you give your results in more
detail?

Best Regards,
Mark Lundquist