Re: Ada2005

[Carsten Freining <freining@informatik.uni-jena.de>]

Sorry it took me very long to answer.

First of all, we did not plan a paper since those meetings (as a review through
the standard with tha rational) where only to get better in understanding Ada as
a programming language. So no paper planned so far.

As one example there is the numeric Error and the Constraint Error. The Numeric
can be removed, since it is the same as the Constraint Error (only renamed). If
there had be a problem (because the renaming was not compatible to Ada83 in all
cases), they have already addressed.

Nearly every PL today has Packages or Units (Java, C# - Namespaces, Delphi) it
has normaly nothing to do with OO.

I will get a hit again, but I havre to state my oppinion at this point with the
Discriminants.

I don't believe they are the good solution to get constants into the "Instances"
and for sure they can be used to initialize Values, but again it is not a
constructor where I can call other Procedures to initialize my instancespecific
Variables. I don't think the discriminatns can be used as the solution for
everything.

I think in a diskussion what has to be changed, we shouldn't go the way "it is
possible to do something in Ada" we should go what can we change include that
more people use Ada. Simplify where possible and not "keep it extremly
complicated at all cost".

Where is the problem of including named constant values into the recordtype and
if necessary keep the discriminant-technique. where is the point of include a
constructor into the recordtype for initializing issues? I can't see a technical
problem in including them. Only because people using Ada as their first
programming language and having figuered out how to work arround (again this
goes against Discriminants and this is my oppinion) it shouldn't be stated "good
programming style".

The context of revising a Language should be "how to clearify, how to simplify,
and how to include new technologies to the language - at best without loosing
the imprortant attributes Ada has.

As an example I asked a couple of months ago the following thing.

I have an access-type to integer lets say

Type IntAccessType is access integer;
IntAccess: IntAccessType;

Subtype IntSubType is integer Range 0..25;

begin
   IntAccess := new IntSubType'(15);
   IntAccess.all := 33;
end;

now with the LRM (Chapter and so on) why is this possible? In my oppinion there
has been a new IntSubType-Instance (doesn't fit really well better would be
container) and the address of the  Instance will be assigned to the access
variable IntAccess. When I assign 33 to the Instance it should be a constraint
error. We went through the LRM and could only assume why this is a propper Ada
programm. Not a plus for the LRM!

Another thing is, that the variables should be initialized by default, or it
should be made necessary to initialize the variables with a value. Points to
make the language saver.

The arbitrary order in evaluating operands for operations should be stated clear
as from left to r�ght. There is no point in still keeping those things up that
make sideeffects compiler dependend (sure I dont like sideeffects - it is not a
good programming style, but a language should fix the order - to give everything
a little more security how something is evaluated.)

If we compare different Languages, then we should check why another language is
more famous then Ada and think about getting those attributes into Ada without
damaging Adas safty, it is not easy for sure, but for Ada to become a more
famous Language, it has to be done.

Just my statement to all the answeres.


Carsten Freining.

PS: I am not really good in programming with ada, since I am working with many
languages. Sure I can overlook tricks that can be used to achieve one of the
goals above. But this isn't about tricks, this is about making programming in a
language easier. Whoever has to decide which Language will be used for a
specific Project doesn't know the tricks in all languages. He must see, that it
is easier in one language then in the one he normaly uses.


Mark Lundquist schrieb:

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