Re: Ada2005

["Mark Lundquist" <no.spam@getalife.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 12386 bytes --]


"Carsten Freining" <freining@informatik.uni-jena.de> wrote in message
news:3C21CA5D.4311D521@informatik.uni-jena.de...
> Sorry it took me very long to answer.

That's OK :-)

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

I'm not sure how this relates (?)... however, as an aside it is quite
enlightening to compare the Ada package construct with Java packages and C++
namespaces.  But that would be another discussion...

>
> 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 I can help you out here...

Don't think of discriminants as "a way to get constants into the instances".
In this context, think of discriminants simply as immutable record
components (although in fact they are more powerful than simply that, as
they can be used in the declaration of other components -- which is why they
are textually separated from the component list rather than being declared
as normal record components with some notation such as 'constant').

Now then... the syntax to declare an object of a discriminated type bears a
superficial resemblance to a constructor with arguments in C++ or Java.
Don't be fooled -- they have nothing to do with each other.

"Constructors" in class-oriented languages exist to solve a
"chicken-and-egg" problem that arises from the "class/instance" paradigm
(that is, the conflation of encapsulation with typing).  The necessity of
constructors is one of the distortions of class-orientation.

In Ada, a constructor is simply a function returning a value of the type.
Unlike other languages, the constructors do not carry the name of the type.
They can be named anything (but this is not confusing, because in Ada
semantics this "constructor" does not actually create the object, only
initializes it).  My own practice is to give all my "constructors" the name
'Create' (and because of overloading, I can and often do have multiple
'Create' functions).

The typical way to define an abstraction in Ada is as a private type, and if
the public view of the type is declared with "unknown discriminants", then
there is no way for a client to declare an uninitialized object:

        package P is
            type T (<>) is private;
            function Create return T;
        private
            type T is //whatever, note the full view does not actually have
to have any discriminants
        end P;
        .
        .
        Foo : P.T;    -- illegal!
        Foo : P.T := P.Create;        -- OK
        Bar : P.T := Foo;                -- of course also OK

So... discriminants and "constructors" are orthogonal.  Use a Create
function for abstraction control and one form of object initialization; use
a discriminant to define an immutable component.

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

Well, by way of "reductio ad absurdum", we could redefine Ada to be C++.
Then, millions of programmers would instantly be using "Ada"! :-)   But
seriously, it seems as though you regard normal and simple Ada programming
techniques as obscure workarounds because they are unfamiliar to you.  With
that as a rationale, you aren't going to get a lot of sympathy for your
ideas about how Ada could be improved (simply because the ideas are
ill-conceived).

> Simplify where possible and not "keep it extremly
> complicated at all cost".

Can you give an example of how these issues of discriminants and/or object
construction give rise to something that is "extremely complicated"?  It's
actually much simpler than constructors in C++, for example.  Or if this is
not the issue you had in mind, then _something_... what do you find
"extremely complicated"?

>
> Where is the problem of including named constant values into the
recordtype and
> if necessary keep the discriminant-technique.

Because it would be "putting legs on a snake".  It would _complicate_ the
language by adding a new way to do something, where there is already a way
that is just as simple and effective.

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

There is nothing to "work around" :-)  Again, you are saying "hey, where are
my constructors?", and the answer is, they don't exist because you don't
need them!  Not even as a convenience.  Not even remotely.  The problem they
exist to solve in class-oriented languages does not exist in Ada.  It's like
if you travelled in rowboats all your life, then you are trying to learn to
ride a bike and saying "hey, where are my oars?"  You don't need them
anymore.  Because rowing is what you know, you might say, "you know,
bicycling would be simpler if it had oars".  No, it would not be simpler.
Learn to ride the bike and then you will understand.

Ada is not and never will be class-oriented.  Complicating the language with
concessions to the class-oriented mindset is not a good idea.

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

Sorry, I guess I missed it...

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

RM 3.10(10).  Look at your declaration of type IntAccessType:

    type IntAccessType is access Integer;

That means that values of this type designate objects of subtype Integer.
It's that simple.

Now, you could have written this (following your naming convention):

    type IntSubTypeAccessType is access IntSubType;

    begin
        IntSubTypeAccess : In

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