Ada2005

Ada2005

[Karel Miklav]

Hello folks,

I've seen Peter Hermann mentioning Ada2005 in his post, but can't google 
out anything. Ada community seems healthy; seeing it has plans for the 
future would make my decision to migrate easier.

Regards, Karel Miklav

Re: Ada2005

[Peter Amey]

Karel Miklav wrote:
> 
> Hello folks,
> 
> I've seen Peter Hermann mentioning Ada2005 in his post, but can't google
> out anything. Ada community seems healthy; seeing it has plans for the
> future would make my decision to migrate easier.
> 

Try googling "Ada 0y" or "Ada0y" instead of Ada2005.  This is much the
same way that 9x eventually became 95.

Peter

Re: Ada2005

[Robert A Duff]

Peter Amey <peter.amey@praxis-cs.co.uk> writes:

> Karel Miklav wrote:
> > 
> > Hello folks,
> > 
> > I've seen Peter Hermann mentioning Ada2005 in his post, but can't google
> > out anything. Ada community seems healthy; seeing it has plans for the
> > future would make my decision to migrate easier.
> > 
> 
> Try googling "Ada 0y" or "Ada0y" instead of Ada2005.  This is much the
> same way that 9x eventually became 95.

Or look at what the ARG is up to, especially "Amendment AI's".
www.ada-auth.org

- Bob

Re: Ada2005

[Ted Dennison]

Karel Miklav <karel@inetis.spppambait.com> wrote in message news:<haAL9.1646$tQ1.100403@news.siol.net>...
> I've seen Peter Hermann mentioning Ada2005 in his post, but can't google 
> out anything. Ada community seems healthy; seeing it has plans for the 

That's funny. I use Google for my newsreader, and when I clicked on
your message it came up as message 57 in the "Ada2005" thread. :-)

Re: Ada2005

[Peter Hermann]

Ted Dennison <dennison@telepath.com> wrote:
> That's funny. I use Google for my newsreader, and when I clicked on
> your message it came up as message 57 in the "Ada2005" thread. :-)

I like Ada2005.
This is a fine deadline for a small incremental useful enhancement
for Ada which should come as soon as possible - but not sooner.
(or later ;-)
The ingredients are visible today.
A name like Ada0y (y for "why") questions the project.

-- 
--Peter Hermann(49)0711-685-3611 fax3758 ica2ph@csv.ica.uni-stuttgart.de
--Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
--http://www.csv.ica.uni-stuttgart.de/homes/ph/
--Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: Ada2005

[Anders Wirzenius]

"Peter Hermann" <ica2ph@iris16.csv.ica.uni-stuttgart.de> wrote in message news:atnhc0$2a3$1@news.uni-stuttgart.de...
>
> A name like Ada0y (y for "why") questions the project.
>

Ada0y associates Finnish-speaking people to a company named Ada Oy, where Oy stands for incorporated or limited (Ada ltd). That may
lead people to get the impression that the Ada language is "owned" by some company and not one of the least commercial connected
programming languages.

Anders

Re: Ada2005

[Ted Dennison]

"Anders Wirzenius" <anders.wirzenius@pp.qnet.fi> wrote in message news:<FSWL9.87$6U2.84@read3.inet.fi>...
> "Peter Hermann" <ica2ph@iris16.csv.ica.uni-stuttgart.de> wrote in message news:atnhc0$2a3$1@news.uni-stuttgart.de...
> >
> > A name like Ada0y (y for "why") questions the project.
> >
> 
> Ada0y associates Finnish-speaking people to a company named Ada Oy, where Oy 

If it associates with being finnished, that can't be a bad thing.


Wait...put down the bats...I'm sorr..ow!ow!

Re: Ada2005

[Anders Wirzenius]

"Ted Dennison" <dennison@telepath.com> wrote in message news:4519e058.0212180648.3f5fac67@posting.google.com...
> "Anders Wirzenius" <anders.wirzenius@pp.qnet.fi> wrote in message news:<FSWL9.87$6U2.84@read3.inet.fi>...
> >
> > Ada0y associates Finnish-speaking people to a company named Ada Oy, where Oy
>
> If it associates with being finnished, that can't be a bad thing.
>
>
> Wait...put down the bats...I'm sorr..ow!ow!

I can imagine the bats are from Sweden ;-)

Ada2005

[Szymon Guz]

Hi
is there any compiler for Ada2005 available ?

regards
Szymon Guz

Re: Ada2005

[Xaelis]

Hi,

On Thu, 2005-03-24 at 15:36 +0100, Szymon Guz wrote:
> is there any compiler for Ada2005 available ?

Yes, the cvs gcc version (4.X) works (not fully Ada 2005 compliant but
already lot of stuff).

You can use a snapshot available here :
http://gcc.gnu.org/snapshots.html

regards

-- 
Alexis Muller
Laboratoire d'Informatique Fondamentale de Lille (LIFL)
Universite de Lille 1 - 59655 Villeneuve d'Ascq Cedex
Web : http://www.lifl.fr/~mullera

Re: Ada2005

[Larry Kilgallen]

In article <d1uj8i$v9f$1@news2.ipartners.pl>, Szymon Guz <guzo@stud.ics.p.lodz.pl> writes:

> is there any compiler for Ada2005 available ?

That would not be possible (except for advances in the physics of
time travel) because Ada2005 has not been finally defined as yet.

Re: Ada2005

[Peter Hermann]

-- 
--Peter Hermann(49)0711-685-3611 fax3758 ica2ph@csv.ica.uni-stuttgart.de
--Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
--http://www.csv.ica.uni-stuttgart.de/homes/ph/
--Team Ada: "C'mon people let the world begin" (Paul McCartney)

Ada2005

[Peter Hermann]

is there consensus on the next standard's name? I have seen
Ada200x
Ada20xx
Ada0x
Ada0y        [why?]
...          [insert your favorite]

What about fixing it to Ada2005?
A well defined deadline exhibiting professionalism.
The idea came to me while observing the pitiful struggles
for standardizing c++ and fortran2000.

-- 
--Peter Hermann(49)0711-685-3611 fax3758 ica2ph@csv.ica.uni-stuttgart.de
--Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
--http://www.csv.ica.uni-stuttgart.de/homes/ph/
--Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: Ada2005

[M. A. Alves]

> is there consensus on the next standard's name? I have seen
> Ada200x
> Ada20xx
> Ada0x
> . . .

How about "AdaNext"?  (As it means the next standard with respect to the
current one at any time it will serve for all times ;-)

-- 
   ,
 M A R I O   data miner, LIACC, room 221   tel 351+226078830, ext 121
 A M A D O   Rua Campo Alegre, 823         fax 351+226003654
 A L V E S   P-4150-180 PORTO, Portugal    mob 351+939354002

Re: Ada2005

[Aaro Koskinen]

"M. A. Alves" <maa@liacc.up.pt> writes:
> How about "AdaNext"?  (As it means the next standard with respect to the
> current one at any time it will serve for all times ;-)

Or maybe "Ada'Next".

A.

-- 
Aaro Koskinen, aaro@iki.fi, http://www.iki.fi/aaro

Re: Ada2005

[Wes Groleau]

Aaro Koskinen wrote:
> 
> Or maybe "Ada'Next".

Ada'Succ  ?  

Naah, the C die-hards would have too much fun with that.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Ada2005

[Marin David Condic]

Ada'Succ would be more appropriate.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Aaro Koskinen" <aaro@iki.fi> wrote in message
news:pdx667e0y5m.fsf@sirppi.helsinki.fi...
>
> Or maybe "Ada'Next".
>

Re: Ada2005

[Ted Dennison]

In article <9v56v8$m40$1@nh.pace.co.uk>, Marin David Condic says...
>
>Ada'Succ would be more appropriate.

Perhaps, but I don't like the way this would be pronounced. I think we should
make things just a *smidge* harder on the anti-Ada folks than this, don't you?
:-)

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: Ada2005

[Alfred Hilscher]

What about Ada-XP (it's trendy, isn't it ;-)

Running on Windows-XP with Athlon-XP.

Marin David Condic wrote:
> 
> Ada'Succ would be more appropriate.
> 
> MDC
> --
> "Aaro Koskinen" <aaro@iki.fi> wrote in message
> news:pdx667e0y5m.fsf@sirppi.helsinki.fi...
> >
> > Or maybe "Ada'Next".
> >

Re: Ada2005

[Martin Dowie]

"Peter Hermann" <ica2ph@iris16.csv.ica.uni-stuttgart.de> wrote in message
news:9v4jsj$bd1$1@infosun2.rus.uni-stuttgart.de...
> is there consensus on the next standard's name? I have seen
> Ada200x
> Ada20xx
> Ada0x
> Ada0y        [why?]
> ...          [insert your favorite]

well, Ada200x shows a lot more confidence than Ada20xx :-)

Has anyone been tasked with this effort in a similar manner
to the way Tucker was for Ada95? The "single lead plus team"
philosophy certainly seems to work.

Re: Ada2005

[Preben Randhol]

On 11 Dec 2001 09:33:07 GMT, Peter Hermann wrote:
> is there consensus on the next standard's name? I have seen
> Ada200x
> Ada20xx
> Ada0x
> Ada0y        [why?]
> ...          [insert your favorite]
> 
> What about fixing it to Ada2005?
> A well defined deadline exhibiting professionalism.

I think that actually one ought to have two deadlines. Say one for 2004
and one for 2005 so that one work towards the 2004 where the standard should
be finished and 2005 being when it should be finally relaesed. In this
way one get a Ada2005 in 2005 and not in 2006  :-)

Preben
-- 
 ()   Join the worldwide campaign to protect fundamental human rights.
'||}
{||'                                           http://www.amnesty.org/

Re: Ada2005

[Larry Kilgallen]

In article <9v4jsj$bd1$1@infosun2.rus.uni-stuttgart.de>, Peter Hermann <ica2ph@iris16.csv.ica.uni-stuttgart.de> writes:
> is there consensus on the next standard's name? I have seen
> Ada200x
> Ada20xx
> Ada0x
> Ada0y        [why?]
> ...          [insert your favorite]
> 
> What about fixing it to Ada2005?
> A well defined deadline exhibiting professionalism.
> The idea came to me while observing the pitiful struggles
> for standardizing c++ and fortran2000.

Ada is already standardized.

Any future goal should be based on features rather than dates.

Re: Ada2005

[Ted Dennison]

In article <9v4jsj$bd1$1@infosun2.rus.uni-stuttgart.de>, Peter Hermann says...
>
>is there consensus on the next standard's name? I have seen
>Ada200x
>Ada20xx
>Ada0x
>Ada0y        [why?]
>...          [insert your favorite]
>
>What about fixing it to Ada2005?

Ada95 was known as Ada9x up until right around 1995 when it became clear that
1995 would be the year that the current (mostly finished) draft would be
approved. I can remember early versions of Gnat that referred to the language as
Ada9x. 

As far as I know, there isn't even really any movement towards making a new
standard. So putting a year on it would be silly in the extreme.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: Ada2005

[Jeffrey Carter]

Ted Dennison wrote:
> 
> Ada95 was known as Ada9x up until right around 1995 when it became clear that
> 1995 would be the year that the current (mostly finished) draft would be
> approved. I can remember early versions of Gnat that referred to the language as
> Ada9x.

It was actually expected in 1994 but slipped over to 1995 Jan. Barnes
even had a book published with "Ada 94" in the title.

Since Ada 83 -> Ada 95 took 12 years, I expect the next version to be
Ada [20]07.

-- 
Jeff Carter
"My brain hurts!"
Monty Python's Flying Circus

Re: Ada2005

[Randy Brukardt]

(I posted this message on Tuesday, but I don't see that it got to
Google, so I figure hardly anyone got it. Sorry to the handful of you
that saw it the first time. - RLB)

Ted Dennison wrote in message ...
>In article <9v4jsj$bd1$1@infosun2.rus.uni-stuttgart.de>, Peter Hermann
says...
>>
>>is there consensus on the next standard's name? I have seen
>>Ada200x
>>Ada20xx
>>Ada0x
>>Ada0y        [why?]
>>...          [insert your favorite]
>>
>>What about fixing it to Ada2005?
>
>Ada95 was known as Ada9x up until right around 1995 when it became
clear that
>1995 would be the year that the current (mostly finished) draft would
be
>approved. I can remember early versions of Gnat that referred to the
language as
>Ada9x.


Therefore x = 5 in this context. Thus the moniker "Ada 0y" (we don't
know the value of 'y' yet). Indeed, it was known as that (informally)
during the Ada 9x design process. As in, "we'll figure out how to do
that in Ada 0y".

>As far as I know, there isn't even really any movement towards making a
new
>standard. So putting a year on it would be silly in the extreme.


There is a plan to produce an amendment in the 2005 time-frame. However,
these things are hard to get done on time. I believe that Ada 9x was
supposed to be finished by the end of 1992. So it was only 25 months
late. And that's pretty good for an international standard.

In any case, there isn't remotely a consensus yet on what should be in
the amendment. So speculating on when the document will be done is quite
premature.

                Randy Brukardt
                ARG Editor

Re: Ada2005

[Peter Hermann]

Peter Hermann <ica2ph@iris16.csv.ica.uni-stuttgart.de> wrote:
> What about fixing it to Ada2005?

some clarification:

Ada9X was called in this way, because the X=5 was not known before.

Every industry standard has to be revised every 10 years (ISO).

The current Ada95 standard is excellent enough to not needing
urgent revision.

-- 
--Peter Hermann(49)0711-685-3611 fax3758 ica2ph@csv.ica.uni-stuttgart.de
--Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
--http://www.csv.ica.uni-stuttgart.de/homes/ph/
--Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: Ada2005

[Larry Kilgallen]

In article <9v7f26$qn2$1@infosun2.rus.uni-stuttgart.de>, Peter Hermann <ica2ph@iris16.csv.ica.uni-stuttgart.de> writes:
> Peter Hermann <ica2ph@iris16.csv.ica.uni-stuttgart.de> wrote:
>> What about fixing it to Ada2005?
> 
> some clarification:
> 
> Ada9X was called in this way, because the X=5 was not known before.
> 
> Every industry standard has to be revised every 10 years (ISO).

I presume that is "revised or reaffirmed".

> The current Ada95 standard is excellent enough to not needing
> urgent revision.

Perhaps the ISO requirement would be met by revising the Ada95 standard
to include any AIs that had been approved since 1995.

Re: Ada2005

[Martin Dowie]

"Peter Hermann" <ica2ph@iris16.csv.ica.uni-stuttgart.de> wrote in message
news:9v7f26$qn2$1@infosun2.rus.uni-stuttgart.de...
> Peter Hermann <ica2ph@iris16.csv.ica.uni-stuttgart.de> wrote:
> > What about fixing it to Ada2005?
>
> some clarification:
>
> Ada9X was called in this way, because the X=5 was not known before.
>
> Every industry standard has to be revised every 10 years (ISO).
>
> The current Ada95 standard is excellent enough to not needing
> urgent revision.

apart from "Interfacing to ..." Annexes for C++, Java at least...

Re: Ada2005

[Carsten Freining]

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.

Another point is the use of unicode characters in identifiers.

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. There are no real bindings between methods (or
procedures) and the belonging class. It is just a package.

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.

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.

Since I work at the university, teaching students about programming
languages, I have to state, that it is not possible, to use the standard in
education. You can only use a subset of Ada, because most things are not
understandable for students, especially in the beginning of their studies. I
think only to make the standard more clear it is neccessary to go through
the standard and make important changes to clearify it.

Greetings,

Carsten Freining.

Peter Hermann schrieb:

> Peter Hermann <ica2ph@iris16.csv.ica.uni-stuttgart.de> wrote:
> > What about fixing it to Ada2005?
>
> some clarification:
>
> Ada9X was called in this way, because the X=5 was not known before.
>
> Every industry standard has to be revised every 10 years (ISO).
>
> The current Ada95 standard is excellent enough to not needing
> urgent revision.
>
> --
> --Peter Hermann(49)0711-685-3611 fax3758 ica2ph@csv.ica.uni-stuttgart.de
> --Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
> --http://www.csv.ica.uni-stuttgart.de/homes/ph/
> --Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: Ada2005

[Peter Hermann]

Carsten Freining <freining@informatik.uni-jena.de> wrote:
> I think Ada95 needs a very urgent revision.

I disagree   (Verzeihung ;-) )

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

well, some things are clearly marked "obsolete" and should be,
after the next revision, commented by the compiler by means of
a warning-type message, of course.
It is the very strength of the Ada philosophy of a very long-term
reliable standard, with no supersets, no subsets, 
aiming at maximum portability.
Removing of features should be done only after a decade_long
warning period.

> Another point is the use of unicode characters in identifiers.

This is not urgent. BTW, the time is not ripe for this, anyway.
Consider the simple German umlaut, how many technical problems
are generated nowadays with all different hardware/software 
we are still working. I stick myself to simple ascii 
in order to save working time, for example.

> 2. There are many problems that have been created by Ada95.

I consider Ada95 a wonderful small delta after Ada83.

> Best example is the object oriented part, because it is not possible to have
> constants as components.

Compiler maintainers may insert the already existing keywork "constant"
in coffee break time.

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

The opposite is true: the Ada concept is more charming IMHO
in that the methods defined in the context belong to the
tagged type. The defining scope is crucial.

> And there is still the fixed length String. I don't think it is neccessary.

The fixed length string is a core requirement for
bread_and_butter_softworkers. 
Tight control over basic static data types is e.g. a necessary need
for efficiency sometimes required.

> It would be better to have only the bounded-length string. For downwards

"only"?
Maybe the comfort to handle them could be enhanced.

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

Although the tools are in Ada95 standard packages,
they could be better shifted to standard Ada syntax, you are right. 
In this matter, even Fortran is more comfortable,
however I would dislike a lack of Ada's strong supervision of truncation.

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

> Since I work at the university, teaching students about programming
> languages, I have to state, that it is not possible, to use the standard in
> education. You can only use a subset of Ada, because most things are not

The typical Pascal/Fortran subset is indeed enough for newcomers.

> understandable for students, especially in the beginning of their studies. I

the advanced students are more cute than you think.

> think only to make the standard more clear it is neccessary to go through
> the standard and make important changes to clearify it.

It is up to you to help clarifying for Ada2005.

Gruesse  (ohne Umlaut  ;-)   )

Peter

-- 
--Peter Hermann(49)0711-685-3611 fax3758 ica2ph@csv.ica.uni-stuttgart.de
--Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
--http://www.csv.ica.uni-stuttgart.de/homes/ph/
--Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: Ada2005

[Ted Dennison]

In article <9v7q8r$1f5$1@infosun2.rus.uni-stuttgart.de>, Peter Hermann says...
>
>Carsten Freining <freining@informatik.uni-jena.de> wrote:
>> Best example is the object oriented part, because it is not possible to have
>> constants as components.
>
>Compiler maintainers may insert the already existing keywork "constant"
>in coffee break time.

Why would anyone want to? Isn't it rather stupid to allocate space in several
objects to a field that will always be the same? I understand why C++ does this:
they don't have packages to put their constants into. So if one wants to
associate a constant with a class, there is no choice but to do it this way and
waste the space. But in Ada we don't have that problem, so why do we need to
duplicate their nasty hack soultion to it?

>> And there is still the fixed length String. I don't think it is neccessary.
>
>The fixed length string is a core requirement for
>bread_and_butter_softworkers. 

I don't think the poster has much experience with Ada strings. Anyone who truly
understood Ada strings would never say something like this. In fact, its almost
the *opposite* of what is true. Its fairly rare that I ever need to use
Ada.Strings.* (well...some of the stuff in Ada.Strings.Fixed comes in handy
fairly often :-) ).

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

This is part of the core misunderstanding here. Its unusual that one ever needs
to "modify" a string, once its initial value is set. Most of what others may
consider "modifications" are actually dynamicly arriving at the initial value,
or building new strings using old ones as a base. Both of these situations can
usually be handled just fine with Ada's "old-fashioned" fixed strings.

I think part of the stumbling block here for beginners is that one of the
exceptions to this is one of the first things they will try to do: Ada.Text_IO.
Perhaps there should be a revision in there to include a version of Get_Line
implemented as a function. That would allow beginners to get off on the right
foot with string manipulation. This seems to be a legitimate problem.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: Ada2005

[Larry Kilgallen]

In article <nxKR7.58838$xS6.95364@www.newsranger.com>, Ted Dennison<dennison@telepath.com> writes:
> In article <9v7q8r$1f5$1@infosun2.rus.uni-stuttgart.de>, Peter Hermann says...
>>
>>Carsten Freining <freining@informatik.uni-jena.de> wrote:
>>> Best example is the object oriented part, because it is not possible to have
>>> constants as components.
>>
>>Compiler maintainers may insert the already existing keywork "constant"
>>in coffee break time.
> 
> Why would anyone want to? Isn't it rather stupid to allocate space in several
> objects to a field that will always be the same? I understand why C++ does this:
> they don't have packages to put their constants into. So if one wants to
> associate a constant with a class, there is no choice but to do it this way and
> waste the space. But in Ada we don't have that problem, so why do we need to
> duplicate their nasty hack soultion to it?

This could be used when some future version of the code would allow
modification but the current one does not.  That sort of issue,
however, could also be handled with a good source code analysis tool,
looking for locations that assign to the field.  The source code
analysis tool is probably better for such a temporary condition,
since it get people familiar with the technique.

Re: Ada2005

[Ted Dennison]

In article <oSRpArsuHQ3k@eisner.encompasserve.org>, Larry Kilgallen says...
(constant record fields)
>This could be used when some future version of the code would allow
>modification but the current one does not.  That sort of issue,

I wouldn't take this as a good example of its need. There are lots of next to
useless features I could suggest, on the theory that they will only be used as
placeholders for when a maintainer might want to change the code to use a useful
feature later.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: Ada2005

[tmoran]

> >> Best example is the object oriented part, because it is not possible to have
> >> constants as components.
> Why would anyone want to? Isn't it rather stupid to allocate space in several
> objects to a field that will always be the same? I understand why C++ does this:
  Not all records are designed de novo.  For instance, in interfacing to
MS Windows you will find lots of places where a particular interface
record field is a constant.

Re: Ada2005

[Ted Dennison]

In article <6ZMR7.38074$ER5.458476@rwcrnsc52>, tmoran@acm.org says...
>
>> >> Best example is the object oriented part, because it is not possible to
>> >> have constants as components.
>> Why would anyone want to? Isn't it rather stupid to allocate space in several
>> objects to a field that will always be the same? I understand why C++ does 

>  Not all records are designed de novo.  For instance, in interfacing to
>MS Windows you will find lots of places where a particular interface
>record field is a constant.

Yeah, I've run into that as well. But that and other such interface-specific
annoyances are adequately handled by putting that yucky interface into a package
that abstracts away such details (as I'm sure you are quite familiar with :-) ).
Ada provides enough help here by allowing you to predesignate the field's value
in the type declaration.

That issue really has nothing to do with why the feature exists in C++, which is
to provide for class-wide constants.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: Ada2005

[Sergey Koshcheyev]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:bbNR7.59101$xS6.96194@www.newsranger.com...
> In article <6ZMR7.38074$ER5.458476@rwcrnsc52>, tmoran@acm.org says...
>
> That issue really has nothing to do with why the feature exists in C++,
which is
> to provide for class-wide constants.

Actually, the const fields in objects are more similar to record
discriminants in Ada in that you set them at construction time and can't
change them later. C++ has class-wide constants too (static const).

Sergey.

>
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>
> No trees were killed in the sending of this message.
> However a large number of electrons were terribly inconvenienced.

Re: Ada2005

[Ted Dennison]

In article <9v87qe$2cpm$1@ns.felk.cvut.cz>, Sergey Koshcheyev says...
>Actually, the const fields in objects are more similar to record
>discriminants in Ada in that you set them at construction time and can't
>change them later. C++ has class-wide constants too (static const).

Ahh. I'm glad I figured that out here rather than the hard way. :-)

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: Ada2005

[Mark Lundquist]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:nxKR7.58838$xS6.95364@www.newsranger.com...
> In article <9v7q8r$1f5$1@infosun2.rus.uni-stuttgart.de>, Peter Hermann
says...
> >
> >Carsten Freining <freining@informatik.uni-jena.de> wrote:
> >> Best example is the object oriented part, because it is not possible to
have
> >> constants as components.
> >
> >Compiler maintainers may insert the already existing keywork "constant"
> >in coffee break time.

It'd be better if others would study RM 3.7 during their coffee break time
:-)

>
> Why would anyone want to? Isn't it rather stupid to allocate space in
several
> objects to a field that will always be the same? I understand why C++ does
this:
> they don't have packages to put their constants into. So if one wants to
> associate a constant with a class, there is no choice but to do it this
way and
> waste the space.

No... you can do this

in Foo.h:

    class Foo {
        static int i;
        .
        .

in Foo.C (typically):

    int Foo::i = something;

It's kind of wack, but we do have this in C++.

I think what the OP means is something like a const data member in C++.  If
so, he should learn about discriminants.

> >> And there is still the fixed length String. I don't think it is
neccessary.
> >
> >The fixed length string is a core requirement for
> >bread_and_butter_softworkers.
>
> I don't think the poster has much experience with Ada strings. Anyone who
truly
> understood Ada strings would never say something like this. In fact, its
almost
> the *opposite* of what is true. Its fairly rare that I ever need to use
> Ada.Strings.* (well...some of the stuff in Ada.Strings.Fixed comes in
handy
> fairly often :-) ).
>
> >> 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.
>
> This is part of the core misunderstanding here. Its unusual that one ever
needs
> to "modify" a string, once its initial value is set. Most of what others
may
> consider "modifications" are actually dynamicly arriving at the initial
value,
> or building new strings using old ones as a base. Both of these situations
can
> usually be handled just fine with Ada's "old-fashioned" fixed strings.

Yes to all of the above.

>
> I think part of the stumbling block here for beginners is that one of the
> exceptions to this is one of the first things they will try to do:
Ada.Text_IO.
> Perhaps there should be a revision in there to include a version of
Get_Line
> implemented as a function.

...such as GNAT's Ada.Strings.Unbounded.Text_IO.Get_Line.  I think it would
be great if that were added to the standard in a language revision.

> That would allow beginners to get off on the right
> foot with string manipulation. This seems to be a legitimate problem.
>

Agreed!

-- mark

Re: Ada2005

[Ted Dennison]

In article <o8NR7.13079$7y.147028@rwcrnsc54>, Mark Lundquist says...
>
>"Ted Dennison" <dennison@telepath.com> wrote in message
>news:nxKR7.58838$xS6.95364@www.newsranger.com...
>> Why would anyone want to? Isn't it rather stupid to allocate space in
>several
>> objects to a field that will always be the same? I understand why C++ does
>this:
>> they don't have packages to put their constants into. So if one wants to
>> associate a constant with a class, there is no choice but to do it this
>way and
>> waste the space.
>
>No... you can do this
>
>in Foo.h:
>
>    class Foo {
>        static int i;
>        .
>        .
>
>in Foo.C (typically):
>
>    int Foo::i = something;

Perhaps that might be marginally better for *some* purposes than doing the same
thing with a deferred constant in Ada. If you like the fact that the value is
hidden away in the body, you can get the exact same effect with an inlined
function if you really want to.

>I think what the OP means is something like a const data member in C++.  If
>so, he should learn about discriminants.

Ahhh. I thought the issue was class-wide constants. Either way though, you can
do this just fine in Ada today.

>> Perhaps there should be a revision in there to include a version of
>> Get_Line implemented as a function.
>
>...such as GNAT's Ada.Strings.Unbounded.Text_IO.Get_Line.  I think it would
>be great if that were added to the standard in a language revision.

Yes; basicly that, but returning "String" instead of
"Ada.Strings.Unbounded.Unbounded_String". Just toss it into Ada.Text_IO and be
done with the whole issue.


---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: Ada2005

[Mark Lundquist]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:rwNR7.59129$xS6.96048@www.newsranger.com...
> In article <o8NR7.13079$7y.147028@rwcrnsc54>, Mark Lundquist says...
> >
> >No... you can do this
> >
> >in Foo.h:
> >
> >    class Foo {
> >        static int i;
> >        .
> >        .
> >
> >in Foo.C (typically):
> >
> >    int Foo::i = something;
>
> Perhaps that might be marginally better for *some* purposes than doing the
same
> thing with a deferred constant in Ada. If you like the fact that the value
is
> hidden away in the body, you can get the exact same effect with an inlined
> function if you really want to.
>

No, you misunderstand me... I'm not saying anything is better in C++ or that
anything would be better if it were different in Ada.  It sounded like you
didn't know about static class members, and were saying that static data
members were a workaround (to get the effect of a classwide constant).  You
said something about the stoopidity of having each instance carry around its
own copy of a constant, and said (I thought) that the only reason to do that
would be because C++ doesn't have anywhere else (like a package) to put
it... but they do.

> >I think what the OP means is something like a const data member in C++.
If
> >so, he should learn about discriminants.
>
> Ahhh. I thought the issue was class-wide constants. Either way though, you
can
> do this just fine in Ada today.
>

True of course.  My point was just that you can also do that in C++ (you
seemed to be denying this).

> >> Perhaps there should be a revision in there to include a version of
> >> Get_Line implemented as a function.
> >
> >...such as GNAT's Ada.Strings.Unbounded.Text_IO.Get_Line.  I think it
would
> >be great if that were added to the standard in a language revision.
>
> Yes; basicly that, but returning "String" instead of
> "Ada.Strings.Unbounded.Unbounded_String". Just toss it into Ada.Text_IO
and be
> done with the whole issue.
>

There you go.  Although I think in practice it wouldn't find as much use as
the unbounded version.  You usually don't do just one Get_Line... :-).

I would guess that GNAT didn't provide this for fixed Strings just because
it's useful only in a special case, and using unbounded strings in that case
is not all that much less convenient than fixed.

Best,
-- mark

Re: Ada2005

[Ted Dennison]

In article <w_NR7.13387$7y.148294@rwcrnsc54>, Mark Lundquist says...
>
>There you go.  Although I think in practice it wouldn't find as much use as
>the unbounded version.  You usually don't do just one Get_Line... :-).

That's not really a problem. This is just a case where you are taking several
succesive string values, so the proper idiom would be to use several successive
string objects:

loop
   declare
      Line : constant String := Ada.Text_IO.Get_Line;
   begin
      -- process line
      exit when Line = "Quit"; -- or whatever
   end;
end loop;

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: Ada2005

[Ted Dennison]

In article <nxKR7.58838$xS6.95364@www.newsranger.com>, Ted Dennison says...
>
>In article <9v7q8r$1f5$1@infosun2.rus.uni-stuttgart.de>, Peter Hermann says...
>>
>>Carsten Freining <freining@informatik.uni-jena.de> wrote:
>>> And there is still the fixed length String. I don't think it is neccessary.
>>
>>The fixed length string is a core requirement for
>>bread_and_butter_softworkers. 
>
>I don't think the poster has much experience with Ada strings. Anyone who truly
>understood Ada strings would never say something like this. In fact, its almost

Just to clarify, "this" above refers to the comments of the original poster, not
Peter (who was right on the money).

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: Ada2005

[Patrick Hohmeyer]

Peter Hermann wrote :
> 
> The opposite is true: the Ada concept is more charming IMHO
> in that the methods defined in the context belong to the
> tagged type. The defining scope is crucial.
> 

Hmmm, perhaps, but not for polymorph methods :

C++ :
Polymorph methods must be declared with the keyword virtual
inside the brackets of the class definition.

Ada95 :
Polymorph methods must be declared after the type definition
but befor it's freezing point.
The freezing point is one of the following <>, there may be
more then one and which one arrives first may actually
depend on your compiler, optimisation flags and your hair-color.

Huh?
In this case I find the C++ definition *way* easier to understand
than this Chapter 13 babbeling of Ada.

IMO this should somehow be revised for Ada0x.

-- 
Patrick Hohmeyer

Re: Ada2005

[Lutz Donnerhacke]

* Patrick Hohmeyer wrote:
[polymorphic]
>In this case I find the C++ definition *way* easier to understand
>than this Chapter 13 babbeling of Ada.

You should read the following to verify your C++ knowledge:

ftp.iks-jena.de/pub/mitarb/lutz/standards/iso/Joyner-Cplusplus-critique-v3.pdf

Re: Ada2005

[Dmitry A. Kazakov]

On Thu, 13 Dec 2001 23:40:59 -0500, Patrick Hohmeyer
<pi3_1415926536@yahoo.ca> wrote:

>Peter Hermann wrote :
>> 
>> The opposite is true: the Ada concept is more charming IMHO
>> in that the methods defined in the context belong to the
>> tagged type. The defining scope is crucial.
>> 
>
>Hmmm, perhaps, but not for polymorph methods :
>
>C++ :
>Polymorph methods must be declared with the keyword virtual
>inside the brackets of the class definition.
>
>Ada95 :
>Polymorph methods must be declared after the type definition
>but befor it's freezing point.
>The freezing point is one of the following <>, there may be
>more then one and which one arrives first may actually
>depend on your compiler, optimisation flags and your hair-color.
>
>Huh?
>In this case I find the C++ definition *way* easier to understand
>than this Chapter 13 babbeling of Ada.
>
>IMO this should somehow be revised for Ada0x.

Egh, there shall be a freezing rule. It is just that in C++ the
freezing point is the } closing the class declaration.

Another question is the keyword "virtual". I think it would be
possible to introduce special keywords / attributes / pragmas
indicating whether a particular parameter is dispatching or not. Like:

type X is tagged ...
procedure Surprize (A : X; B : X'Do_not_dispatch);  -- (:-))

Presently all non-class-wide parameters (of the type) are dispatching.
In C++ all parameters are non-dispatching, except the hidden one, if
the keyword virtual is applied. I am not very sure that
non-dispatching parameters make much sense. But in any case Ada's way
is more consistent (consider multiple dispatch etc)

Regards,
Dmitry Kazakov

Re: Ada2005

[Matthew Heaney]

"Patrick Hohmeyer" <pi3_1415926536@yahoo.ca> wrote in message
news:K2fS7.15363$Us5.3441773@news20.bellglobal.com...
> In this case I find the C++ definition *way* easier to understand
> than this Chapter 13 babbeling of Ada.

Most of the time you don't have to think about the freezing rules -- if you
try to do something that's not allowed then your compiler will tell you.

This is not unlike the rules for using static_cast vs reinterpret_cast in
C++.  Rather than try to figure out which one to use, just use a
static_cast, and then let the compiler tell you that you need to use a
reinterpret_cast instead.

The basic idea with freezing rules for tagged types is that all the
primitive operations ("virtual methods") for a type have to be known at the
point of derivation.  For example:

package P is
   type T is abstract tagged limited null record;
   procedure Op (O : in out T) is abstract;

   type NT is new T with null record;
   procedure Op (O : in out NT);  --OK

   procedure Another_Op (O : in out T) is abstract;  --primitive op declared
too late
end P;

The declaration of Another_Op for type T comes too late ("after the freezing
point"), because all the primitive operations have to be known at the time
of declaration of type NT.  (This is because they are "implicitly declared"
at the point of declaration of type NT.)

Here's the output of my compiler:

gcc -c -Ic:\ -I- c:\p.ads
p.ads:5:04: warning: no primitive operations for "T" after this line
p.ads:8:14: this primitive operation is declared too late
gnatmake: "c:\p.ads" compilation error


The fix is simple enough:

package P is
   type T is abstract tagged limited null record;
   procedure Op (O : in out T) is abstract;
   procedure Another_Op (O : in out T) is abstract;  --OK

   type NT is new T with null record;
   procedure Op (O : in out NT);  --OK
   procedure Another_Op (O : in out NT); --OK

end P;

Re: Ada2005

[Mark Lundquist]

"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

Re: Ada2005

[Mark Lundquist]

I ("Mark Lundquist" <mlundquist2@attbi.com>) wrote in message
news:Q_MR7.13041$7y.146471@rwcrnsc54...
>
> 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).

Actually, I can take back the last part of that.  Flat class-oriented
languages that allow classwide object declarations (e.g. static data members
in C++ and Java) are no better off in this way than Ada.

(Smalltalk provides a higher level of encapsulation for objects themselves,
since all objects are either class or instance variables, which are private.
But Smalltalk is also flat, so it doesn't have the level of encapsulation
for classes themselves that Ada has).

-- mark
http://home.attbi.com/~mlundquist2/consulting

Re: Ada2005

[Stephen Leake]

"Mark Lundquist" <no.spam@getalife.com> writes:

> Actually, I can take back the last part of that.  Flat class-oriented
> languages that allow classwide object declarations (e.g. static data members
> in C++ and Java) are no better off in this way than Ada.

If you are saying that C++ has a flat namespace, I think you are
wrong. C++ "namespaces" provide at least one layer below global, and I
think they can be nested. (One of these days I need to buy a new C++
reference; mine is only Stroustrup's second edition, which doesn't
have namespaces :).


-- 
-- Stephe

Re: Ada2005

[Mark Lundquist]

"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:u8zc76k04.fsf@gsfc.nasa.gov...
> "Mark Lundquist" <no.spam@getalife.com> writes:
>
> > Actually, I can take back the last part of that.  Flat class-oriented
> > languages that allow classwide object declarations (e.g. static data
members
> > in C++ and Java) are no better off in this way than Ada.
>
> If you are saying that C++ has a flat namespace, I think you are
> wrong. C++ "namespaces" provide at least one layer below global, and I
> think they can be nested.

I know... however, C++ still has the almost-flat *scoping* of C, and while
C++ namespaces are hierarchial, all elements of the hierarchy are public,
resulting in flat visibility at the top ("header file") layer (compare with
Ada, where a package spec may occur within a body (textually or as a
subunit) or as a private child).

My point is, given a class declared in a header file, any other source file
may #include that file, reference the class, create and manipulate instances
of it, diddle with any diddleable static class members, and call the class'
static functions.

C++ namespaces impose a naming regime, but provide no encapsulation of
classes or objects.

Cheers,
Mark

Re: Ada2005

[Stephen Leake]

"Mark Lundquist" <no.spam@getalife.com> writes:

> My point is, given a class declared in a header file, any other source file
> may #include that file, reference the class, create and manipulate instances
> of it, diddle with any diddleable static class members, and call the class'
> static functions.
> 
> C++ namespaces impose a naming regime, but provide no encapsulation of
> classes or objects.

This is true. Thanks for the clarification. Long live Ada :).


-- 
-- Stephe

Re: Ada2005

[Dmitry A. Kazakov]

On Wed, 12 Dec 2001 18:04:32 GMT, "Mark Lundquist"
<mlundquist2@attbi.com> wrote:

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

Of course it is not. In contrary, the opposite is a problem. If
methods *belong* to a type then there is no place for multiple
dispatch [which is partially supported by Ada]. "Methods *of* object"
are inherently inconsistent from this point view.

However, what people criticizing Ada usualy want, is just a syntax
sugar, which would allow to refer methods using postfix form if there
is only one dispatching [or class-wide] argument and it is the first
one.

I think in a future revision there could be some variant of rename
statement which would allow to do this and also the opposite thing
[for "methods" of protected objects and tasks which are always called
using the postfix form]. For instance:

type Ellipse is tagged ...
procedure Draw (Figure : Ellipse, Where : Point);
entry Ellipse.Draw (Where : Point) renames Draw;
...............
task type Server is
   entry Shut_Down;
end Server:
procedure Shut_Down (Arg : in out Server) renames Server.Shut_Down;

Regards,
Dmitry Kazakov

Re: Ada2005

[Ray Blaak]

dmitry@elros.cbb-automation.de (Dmitry A. Kazakov) writes:
> However, what people criticizing Ada usualy want, is just a syntax
> sugar, which would allow to refer methods using postfix form if there
> is only one dispatching [or class-wide] argument and it is the first
> one.

Like me.

> I think in a future revision there could be some variant of rename
> statement which would allow to do this and also the opposite thing
> [for "methods" of protected objects and tasks which are always called
> using the postfix form]. For instance:
> 
> type Ellipse is tagged ...
> procedure Draw (Figure : Ellipse, Where : Point);
> entry Ellipse.Draw (Where : Point) renames Draw;

Why not make it automatic? The extra declaration is tedious and requires extra
maintenance.

Given:

  e : Ellipse;

then have

  e.Draw(p)

be valid iff Draw exists with an Ellipse as its first parameter.

Then it is truly just an alternate syntax to be used if desired, and not used
if not.

Where it gets wierd, I suppose, is if one has an "in out" or "out"
parameter. One wants to allow update methods, but does e.Draw(p) make sense if
e is completely replaced?

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@telus.net                                The Rhythm has my soul.

Re: Ada2005

[Dmitry A. Kazakov]

On 17 Dec 2001 09:50:30 -0800, Ray Blaak <blaak@telus.net> wrote:

>dmitry@elros.cbb-automation.de (Dmitry A. Kazakov) writes:
>> However, what people criticizing Ada usualy want, is just a syntax
>> sugar, which would allow to refer methods using postfix form if there
>> is only one dispatching [or class-wide] argument and it is the first
>> one.
>
>Like me.
>
>> I think in a future revision there could be some variant of rename
>> statement which would allow to do this and also the opposite thing
>> [for "methods" of protected objects and tasks which are always called
>> using the postfix form]. For instance:
>> 
>> type Ellipse is tagged ...
>> procedure Draw (Figure : Ellipse, Where : Point);
>> entry Ellipse.Draw (Where : Point) renames Draw;
>
>Why not make it automatic? The extra declaration is tedious and requires extra
>maintenance.
>
>Given:
>
>  e : Ellipse;
>
>then have
>
>  e.Draw(p)
>
>be valid iff Draw exists with an Ellipse as its first parameter.

Maybe. Though, then you should allow funny constructions like:
e."abs", when function "abs" (X: Ellipse) return ... is defined. Also
you should support fully qualified forms like:

e.Geometry.Flat.Figures.Conic.Float_Figures.Ellipse.Draw (p);

>Then it is truly just an alternate syntax to be used if desired, and not used
>if not.
>
>Where it gets wierd, I suppose, is if one has an "in out" or "out"
>parameter. One wants to allow update methods, but does e.Draw(p) make sense if
>e is completely replaced?

Neither "in out" nor "out" mean that the argument is replaced. It
depends on by-copy vs. by-reference parameter passing mode. Though,
for tagged types by-reference is a requirement [to support redispatch,
I suppose (:-()].

procedure Draw (Figure : Ellipse, Where : Point); is an equivalent to
C++

virtual void Draw (Point Where) const;

procedure Draw (Figure : in out Ellipse, Where : Point); is an
equivalent to

virtual void Draw (Point Where);

Only for "out" C++ has no analogy. 

Regards,
Dmitry Kazakov

Re: Ada2005

[Ray Blaak]

dmitry@elros.cbb-automation.de (Dmitry A. Kazakov) writes:
> On 17 Dec 2001 09:50:30 -0800, Ray Blaak <blaak@telus.net> wrote:
> Maybe. Though, then you should allow funny constructions like:
> e."abs", when function "abs" (X: Ellipse) return ... is defined. Also
> you should support fully qualified forms like:
> 
> e.Geometry.Flat.Figures.Conic.Float_Figures.Ellipse.Draw (p);

Why? It is misleading, since object.something usually means something in the
context of object.

I would be perfectly willing to live with the restriction that one cannot do
e.Draw unless the Draw method was directly visible.

Alternatively, the compiler could be smarter, and look for the symbol "Draw"
in the context where the type of e was defined.

I also have no problem with e."abs", or e."+", given that one can already do
the strange "+"(1, 2) directly anyway.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@telus.net                                The Rhythm has my soul.

Re: Ada2005

[Dmitry A. Kazakov]

On 18 Dec 2001 11:51:09 -0800, Ray Blaak <blaak@telus.net> wrote:

>dmitry@elros.cbb-automation.de (Dmitry A. Kazakov) writes:
>> On 17 Dec 2001 09:50:30 -0800, Ray Blaak <blaak@telus.net> wrote:
>> Maybe. Though, then you should allow funny constructions like:
>> e."abs", when function "abs" (X: Ellipse) return ... is defined. Also
>> you should support fully qualified forms like:
>> 
>> e.Geometry.Flat.Figures.Conic.Float_Figures.Ellipse.Draw (p);
>
>Why? It is misleading, since object.something usually means something in the
>context of object.

Because, actually "context of object" is rather an imaginary thing.
Consider overriding. What if the parent's Draw should be called? Then
if sometimes MI will be supported, what about name clashes induced by
multiple inheritance?

>I would be perfectly willing to live with the restriction that one cannot do
>e.Draw unless the Draw method was directly visible.
>
>Alternatively, the compiler could be smarter, and look for the symbol "Draw"
>in the context where the type of e was defined.
>
>I also have no problem with e."abs", or e."+", given that one can already do
>the strange "+"(1, 2) directly anyway.

There still could be hidden pitfalls with an automatic inference of
postfix <-> functional forms. Let more knowledgeable people say.

Regards,
Dmitry Kazakov

Re: Ada2005

[Mark Lundquist]

"Dmitry A. Kazakov" <dmitry@elros.cbb-automation.de> wrote in message
news:3c204d01.387078@News.CIS.DFN.DE...
> >> Also
> >> you should support fully qualified forms like:
> >>
> >> e.Geometry.Flat.Figures.Conic.Float_Figures.Ellipse.Draw (p);
> >
> >Why? It is misleading, since object.something usually means something in
the
> >context of object.
>
> Because, actually "context of object" is rather an imaginary thing.
> Consider overriding. What if the parent's Draw should be called? Then
> if sometimes MI will be supported, what about name clashes induced by
> multiple inheritance?

(not that I like this alternate syntax idea, but...)  Don't forget that the
inherited primitives of a type are implicitly declared at the point of the
type declaration.

Re: Ada2005

[Ray Blaak]

dmitry@elros.cbb-automation.de (Dmitry A. Kazakov) writes:
> On 18 Dec 2001 11:51:09 -0800, Ray Blaak <blaak@telus.net> wrote:
> >dmitry@elros.cbb-automation.de (Dmitry A. Kazakov) writes:
> >> Also you should support fully qualified forms like:
> >> 
> >> e.Geometry.Flat.Figures.Conic.Float_Figures.Ellipse.Draw (p);
> >
> >Why? It is misleading, since object.something usually means something in the
> >context of object.
> 
> Because, actually "context of object" is rather an imaginary thing.
> Consider overriding. What if the parent's Draw should be called? Then
> if sometimes MI will be supported, what about name clashes induced by
> multiple inheritance?

"context of object" = "scope where object's type is defined"

If this syntactical transformation is only supported for primitive operations,
then the full information should be available in the context where the
object's type is defined, including inherited routines.

So, these:

  e.Draw(p);
  The_Canvas.First_Shape.Draw(p);

would be known to be possible method calls, since "Draw" would not be record
fields or protected object entries. Assuming that e's type is in the package
E_Shape and The_Canvas.First_Shape's type in in the package Shape, the compiler
then tries:

  E_Shape.Draw(e, p);
  Shape.Draw(The_Canvas.First_Shape, p);

And then regular Ada rules for routine matching kick in, including possible
future MI and multiple dispatch enhancements.

If the object's type is directly visible, the transformation could be just:

  Draw(e, p);

and again, regular Ada rules could apply.

> >I also have no problem with e."abs", or e."+", given that one can already do
> >the strange "+"(1, 2) directly anyway.
> 
> There still could be hidden pitfalls with an automatic inference of
> postfix <-> functional forms. Let more knowledgeable people say.

I would be happy to learn about them. Since I am only discussing syntactical
transformations that can be mapped to existing Ada semantics, I expect,
perhaps incorrectly, that any pitfalls can be readily dealt with.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@telus.net                                The Rhythm has my soul.

Re: Ada2005

[Mark Lundquist]

"Ray Blaak" <blaak@telus.net> wrote in message
news:uvgf5rb15.fsf@telus.net...
> dmitry@elros.cbb-automation.de (Dmitry A. Kazakov) writes:
> > However, what people criticizing Ada usualy want, is just a syntax
> > sugar, which would allow to refer methods using postfix form if there
> > is only one dispatching [or class-wide] argument and it is the first
> > one.
>
> Like me.
>
> > I think in a future revision there could be some variant of rename
> > statement which would allow to do this and also the opposite thing
> > [for "methods" of protected objects and tasks which are always called
> > using the postfix form]. For instance:
> >
> > type Ellipse is tagged ...
> > procedure Draw (Figure : Ellipse, Where : Point);
> > entry Ellipse.Draw (Where : Point) renames Draw;
>
> Why not make it automatic? The extra declaration is tedious and requires
extra
> maintenance.
>
> Given:
>
>   e : Ellipse;
>
> then have
>
>   e.Draw(p)
>
> be valid iff Draw exists with an Ellipse as its first parameter.
>
> Then it is truly just an alternate syntax to be used if desired, and not
used
> if not.
>

Doesn't it make a mishmash of the name resolution rules?  Consider

        type Note is private;

        function Pitch (Subject : Note) return Note_Properties.Pitch;
        function Length (Subject : Note) return Note_Properties.Length;

    private

        type Note is record
            Pitch : Note_Properties.Pitch;
            Length : Note_Properties.Lenght;
        end record;

In the body of the package, how do you resolve the name "X.Pitch" for an X
of type Note?

Re: Ada2005

[Ray Blaak]

"Mark Lundquist" <no.spam@getalife.com> writes:
> "Ray Blaak" <blaak@telus.net> wrote in message
> Doesn't it make a mishmash of the name resolution rules?  Consider
> 
>         type Note is private;
> 
>         function Pitch (Subject : Note) return Note_Properties.Pitch;
>         function Length (Subject : Note) return Note_Properties.Length;
> 
>     private
> 
>         type Note is record
>             Pitch : Note_Properties.Pitch;
>             Length : Note_Properties.Lenght;
>         end record;
> 
> In the body of the package, how do you resolve the name "X.Pitch" for an X
> of type Note?

First off, I should say that I am not strongly advocating this change to be
made to Ada, even though I would prefer if I could do this kind of thing.

This is really only a thought experiment.

At any rate, I would resolve X.Pitch by saying that record fields "win" if the
field is accessible. The Pitch method would win only if:

a) Note is accessible as a tagged type at the point of call
b) Pitch is not accessible as a field at the point of call
c) Pitch is accessible as a primitive operation at the point of call

If both the field and method are accessible and are ambiguous, one could just
choose the field, since that is existing Ada semantics. A warning about the
ambiguity could possibly also be reported, so as to inform the user.

For regular record types (or any other type, for that matter), this syntactic
transformation need not apply.

I only prefer it for OO programming, where I tend to think in terms of asking
an object to do something, as opposed to asking something to be done to an
object, if you know what I mean.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@telus.net                                The Rhythm has my soul.

Re: Ada2005

[Dmitry A. Kazakov]

On Wed, 19 Dec 2001 18:20:41 GMT, "Mark Lundquist"
<no.spam@getalife.com> wrote:

>
>"Ray Blaak" <blaak@telus.net> wrote in message
>news:uvgf5rb15.fsf@telus.net...
>> dmitry@elros.cbb-automation.de (Dmitry A. Kazakov) writes:
>> > However, what people criticizing Ada usualy want, is just a syntax
>> > sugar, which would allow to refer methods using postfix form if there
>> > is only one dispatching [or class-wide] argument and it is the first
>> > one.
>>
>> Like me.
>>
>> > I think in a future revision there could be some variant of rename
>> > statement which would allow to do this and also the opposite thing
>> > [for "methods" of protected objects and tasks which are always called
>> > using the postfix form]. For instance:
>> >
>> > type Ellipse is tagged ...
>> > procedure Draw (Figure : Ellipse, Where : Point);
>> > entry Ellipse.Draw (Where : Point) renames Draw;
>>
>> Why not make it automatic? The extra declaration is tedious and requires
>extra
>> maintenance.
>>
>> Given:
>>
>>   e : Ellipse;
>>
>> then have
>>
>>   e.Draw(p)
>>
>> be valid iff Draw exists with an Ellipse as its first parameter.
>>
>> Then it is truly just an alternate syntax to be used if desired, and not
>used
>> if not.
>>
>
>Doesn't it make a mishmash of the name resolution rules?  Consider
>
>        type Note is private;
>
>        function Pitch (Subject : Note) return Note_Properties.Pitch;
>        function Length (Subject : Note) return Note_Properties.Length;
>
>    private
>
>        type Note is record
>            Pitch : Note_Properties.Pitch;
>            Length : Note_Properties.Lenght;
>        end record;
>
>In the body of the package, how do you resolve the name "X.Pitch" for an X
>of type Note?

We already have this case with protected types:

protected type X is
    function Y return Integer;
private
    Y : Integer;  -- Illegal!
end X;

Thus the compiler should complain about:

Pitch : Note_Properties.Pitch;

Regards,
Dmitry Kazakov

Re: Ada2005

[Carsten Freining]

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

Re: Ada2005

[Mark Lundquist]

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

Re: Ada2005

[Matthew Woodcraft]

Carsten Freining <freining@informatik.uni-jena.de> writes:

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

[and was surprised that this compiles and runs without error]

It seems to me there is a good question here: why is the allocator
allowed to compile? Is there ever a case where you want to allocate an
object using a different subtype to the one specified in the access
type? Seems to me this would only cause confusion for the maintainer.

What problems would be caused if 4.8 para 3 were modified like this?

    3. The expected type for an allocator shall be a single
-      access-to-object type whose designated type covers the type
-      determined by the subtype_mark of the subtype_indication or
+      access-to-object type whose designated subtype statically
+      matches the subtype_mark of the subtype_indication or
       qualified_expression.

At the least, a warning in this case might have reduced the poster's
confusion.

-M-

Re: Ada2005

[Mark Lundquist]

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

Shoot!  I hit the wrong key and sent my message before it was done!

As I was saying, you could have written this:

     type IntSubtypeAccessType is access IntSubtype;
     IntSubtypeAccess : IntSubtypeAccessType

     begin
        IntSubtypeAccess := new IntSubtype'(15);
        IntSubtypeAccess.all := 33;
     end;

and then, you *would* have gotten a Constraint_Error, because the expression
in the assignment is out of the range of the designated subtype of the
access type.  (In fact, in this program most compilers will give you a
warning that the exception will be raised at runtime).

> In my oppinion there
> has been a new IntSubType-Instance (doesn't fit really well better would
be
> container)

'Object' is the correct Ada term...

> and the address of the  Instance will be assigned to the access
> variable IntAccess.

Your opinion is wrong :-)

    new IntSubtype'(15)

does not "create a new IntSubtype instance".  This part _is_ a little bit
confusing, I'll grant you.  It creates a new object of the base type of
IntSubtype (i.e., Integer).  But if it were not this way, all kinds of other
things would end up being much _more_ confusing, trust me :-).  The point
is, you didn't know how to write it correctly, and now you do :-).  But I
think part of your confusion may arise from not really understanding
subtypes... I wonder if perhaps you are thinking of them as something like a
"subclass"?  One really must have a proper understanding of the relationship
between types and subtypes.  Once you do, the semantics of allocators makes
perfect sense.  Individual objects do not carry around little tags that say
what their subtype constraints are, which is what you are really asking for.

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

Not a plus for you! :-)  The rule (3.10(10) as I said in my first post,
before I cut myself off :-) is not hard to find or understand, it's right
there in the section of the RM where access types are introduced.

But now you know how to write this correctly.  Declare the access type to
designate the subtype you want.

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

Both of those things are very unlikely to be changed, for reasons having to
do with performance.

With regard to default initialization... you should know if you do not
already that all objects of an access type are default initialized to null.
For other types, default initialization does not actually make programs
_safer_; it just makes an erroneous program fail in a more consistent
manner.  Static analysis tools can be used to check for dependence on
uninitialized variables.

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

There are many reasons why languages vary in popularity, and technical
features are only one factor.

Best Regards,
mark

--
-------------
Reply by email to: Mark dot Lundquist at ACM dot org
Consulting services: http://home.attbi.com/~mlundquist2/consulting

Re: Ada2005

[Mark Lundquist]

"Mark Lundquist" <no.spam@getalife.com> wrote in message
news:GInU7.13567$NM4.3196979@rwcrnsc53...

I could have said this more clearly:

>
>     new IntSubtype'(15)
>
> does not "create a new IntSubtype instance".  This part _is_ a little bit
> confusing, I'll grant you.  It creates a new object of the base type of
> IntSubtype (i.e., Integer)

...whose subtype is the designated subtype of the access type, which in this
example was also Integer.  Hopefully I didn't add to the confusion!

-- mark

Re: Ada2005

[Georg Bauhaus]

Carsten Freining <freining@informatik.uni-jena.de> wrote:
 
: Best example is the object oriented part, because it is not possible to have
: constants as components.

Others have hinted to non-defaulted record dicriminants,
and to constants declared in the same scope as the components.


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

Well, thats an incomplete statement at best.
? := {T| t is a technique}
I guess you are referring to a "principle" where one class
"is" one source file, like in Eiffel or Java with its ubiquitous
singletons? :-)

: Since I work at the university, teaching students about programming
: languages, I have to state, that it is not possible, to use the standard in
: education.

Now, you say "about programming languages". Does that mean
concepts of programming languages or concepts of programming?
Of course you cannot in general use an ISO standard for teaching
programming, or whatever. I guess you have not been considering
this, have you?  ISO standards are highly specialized
technical documents for people who have to understand every little
detail, and who are  familiar with the underlying concepts,
does this have to be said ?!



You can only use a subset of Ada, because most things are not
: understandable for students, especially in the beginning of their studies.

Is there any language for which this is not true???
Of course real life programming languages are anything but easily
understandable to the last bit.  It takes time and effort to
understand matters even in some languages that some consider "simpler"
than Ada. SICP, say, is not a book that you fully absorb in a few weeks if
you are new to programming and also have some other things to do (at a
university.)
Some have been _designed_ for teaching as if they were a subset of some
language, at least so it seems. (Logo, e.g.)

I
: think only to make the standard more clear it is neccessary to go through
: the standard and make important changes to clearify it.

Clarifying does mean what?  Some people prove things from the standard,
being "language lawyers" the need to be able to do so,
and how should that be possible at all were that standard so unclear?
If clarifying means easily grasped by beginning students, then, again
that's not what standards are for, don't you think? Why else would
we have text books?

Given that you want to expose students to programming language
concepts, then every concept is best captured by some language
that supports this very concept well. Trivially true. Some languages support
few concepts well, some languages support many concepts well or relativley
well. I think Ada is among the latter.

Given that you want to teach programming, there is more to say
aboubt choosing a language as a vehicle. One might asked others
about their experience in doing so, and one might weigh their
arguements and their non-technical preferences for a language
(something that appears to be much more influential in language choice.)
You can benefit from teaching tradition! Don't just browse standards
(you would have noted the record discriminants otherwise).

(If your teaching efforts are about OO, and if you will be teaching
newbies, perhaps even non-mathematicians, let me warn you that it might
turn out to be easy to explain inheritance trees or graphs in the
abstract, but, surprisingly, not that easy to explain what a function
or procedure is and does (Java experience, first steps leaving
static void main(String[] args) { interpreter mode code; }))

Georg
(not a university teacher, but having done some teaching;
not much, but even the few occasions over the years let
me think that it is definitely better to have a language
with clear and meaningful symbols and names, like Ada.
Cheers.>)