Ada2005

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

Math Libraries (was Re: Ada2005)

[Marin David Condic]

We have in Ada a useful package: Ada.Numerics.Generic_Elementary_Functions
that works fine for floating point types.

Is there any reason not to include in Ada200x similar packages for generic
fixed and decimal types? It seems we ought to be able to compute logarithms,
square roots, etc. for numeric types other than floating point types, eh?

Would there be any reason not to expand the math functions beyond what is
already there? Math is pretty cheap to implement when compared to some of
the other suggested extensions to the language and it would definitely be
attractive to a given audience that might currently still be relying on
Fortran. (See also the discussion elsewhere about standard libraries...)

What math functions (or math branches) would be most desirable to add to the
language by way of some packages under Ada.Numerics?

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/

Re: Math Libraries (was Re: Ada2005)

[FGD]

Marin David Condic wrote:

> We have in Ada a useful package: Ada.Numerics.Generic_Elementary_Functions
> that works fine for floating point types.
> 
> Is there any reason not to include in Ada200x similar packages for generic
> fixed and decimal types? It seems we ought to be able to compute logarithms,
> square roots, etc. for numeric types other than floating point types, eh?


There is a range issue here, most of these functions will map out of the 
range of the original type or will have unsatisfactory precision within 
the original type--such extensions are generally useless. Converting to 
float and using the float result is usually the best solution. For most 
of the remaining cases converting back from float to the original type 
is the most efficient way to compute the desired result. For the very 
few remaining cases, the programer should be able to supply efficient 
algorithms.

I think all of this was considered when designing Ada95.


> Would there be any reason not to expand the math functions beyond what is
> already there? Math is pretty cheap to implement when compared to some of
> the other suggested extensions to the language and it would definitely be
> attractive to a given audience that might currently still be relying on
> Fortran. (See also the discussion elsewhere about standard libraries...)

 >

> What math functions (or math branches) would be most desirable to add to the
> language by way of some packages under Ada.Numerics?

One thing I like about Ada.Numerics is that, with the exception of 
random numbers, it contains only functions which are commonly 
implemented directly in hardware or nearly so. I like this RIS 
approach---and I would like future extensions to adhere to this 
philosophy. (Although the use of the word "Elementary" could be used to 
distinguish extensions which do.)

Should the numerics annex be extended to include more complex functions 
and types. I would like to see more discrete arithmetic types. I would 
love to see, in order of preference:
(1) Binary Galois fields.
(2) Crypto-secure random numbers.
(3) More modular operations. (e.g. multiplicative inverses & efficient 
exponentiation.)
(4) Built-in multiprecision types.
These have in common that highly efficient but hopelessly target 
dependent algorithms are known for computing these.

Most of the stuff I do now is discrete, so I really have no idea what 
would be best for continuous types. But I guess that operations that 
could take advantage of SIMD extensions of some processors would be 
useful. Well anything that would likely speed up a Fourier Transform 
would be a bonus. For example like Fortran, built-in point to point 
multiplication of arrays would be good.

On the abstraction side, the fact that arrays and functions are 
addressed with the same syntax is a fun thing in Ada. Perhaps this could 
be taken further?

-- Frank

Re: Math Libraries (was Re: Ada2005)

[Marin David Condic]

I could see that objection, but it still seems that it would be nice to have
something like this available for other numeric types. Personally, I'd be
willing to live with the possibility that for a number of particularly small
fixed or decimal types, the computations might generate Constraint_Error so
long as for the ones that were big enough I got a result. Its up to the user
to define types of sufficient size and precision to have something like Sqrt
make sense for it.

Clearly, the original package was intended to line up nicely with hardware
or OS supplied libraries and I see no reason that it should change. I'm
thinking along the lines of extention in other packages that might have to
do their computation strictly in the Ada language. It might not even need to
be under Ada.Numerics.

I might not object if the underlying implementation did conversions to some
floating point type and converted the result back to whatever it had to.
Sure, I could do it myself, but having things like Log and Sqrt available
for fixed and decimal types seems almost as fundamental as having "+" and
"-". Its pretty basic to most math that is just a bit more complex than
balancing my checkbook. (Maybe even there as well - you need Sqrt to compute
interest, don't you? :-)

You're probably right about it being considered and rejected for Ada95.
Maybe its time to reconsider?

Other extensions I think would be useful here would be vector and matrix
math. That shows up often enough to be generally useful and there are
already a number of packages available to do it. So it could be a case of
standardizing on an existing library - if I dare bring that up! :-)

I'd also vote for statistics - partly because I think it would get used a
lot and partly because I just like statistics. (A friend once described it
this way: Statistics is to Math what The National Enquirer is to Journalism.
:-)

Other languages provide some math capabilities, but generally don't go this
far. That would make Ada even more useful in the math realm than it already
is. And I don't think its a stretch too far from the beaten path to cover
vectors, matricese and statistics. Those areas are used often enough that it
wouldn't seem "strange" to support them.

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/


"FGD" <presbeis@look.ca> wrote in message news:3C22468C.30901@look.ca...
>
>
> There is a range issue here, most of these functions will map out of the
> range of the original type or will have unsatisfactory precision within
> the original type--such extensions are generally useless. Converting to
> float and using the float result is usually the best solution. For most
> of the remaining cases converting back from float to the original type
> is the most efficient way to compute the desired result. For the very
> few remaining cases, the programer should be able to supply efficient
> algorithms.
>
> I think all of this was considered when designing Ada95.
>

Re: Math Libraries (was Re: Ada2005)

[FGD]

I agree that linear algebra types such as vector and matrix would be a 
nice language extension. These would benefit the most from hardware 
extensions such as SIMD, and having them within the language would 
ensure that all target machines are exploited to their full potential.

I would like to be able to write

    type Domain_Space is vector (1 .. D) of Float;
    type Range_Space  is vector (1 .. R) of Float;
    type Transform is matrix (Domain_Space, Range_Space);

    F, G : Transform;
    U, V : Domain_Space;
    X, Y : Range_Space;
    S : Float;

    ...................

    X := F * U;
    Y := (F + G) * (U + S * V) - X;

where all operators are defined within the language, all checks made at 
compile time. Note that the semantics become pretty complicated here for 
language defined objects---some might object to that. It's very unusual 
to have predefined mixed-type operations. I think vector and matrix 
should be fairly distinct from array. It would be very inconvenient if 
any array of floats came with predefined +, -, *, etc.

I'm not too sure about stats. Basic stats can be handled with linear 
algebra and elementary math. The problem is that it's not clear where to 
stop. It's something to think about...

-- Frank

Marin David Condic wrote:

> I could see that objection, but it still seems that it would be nice to have
> something like this available for other numeric types. Personally, I'd be
> willing to live with the possibility that for a number of particularly small
> fixed or decimal types, the computations might generate Constraint_Error so
> long as for the ones that were big enough I got a result. Its up to the user
> to define types of sufficient size and precision to have something like Sqrt
> make sense for it.
> 
> Clearly, the original package was intended to line up nicely with hardware
> or OS supplied libraries and I see no reason that it should change. I'm
> thinking along the lines of extention in other packages that might have to
> do their computation strictly in the Ada language. It might not even need to
> be under Ada.Numerics.
> 
> I might not object if the underlying implementation did conversions to some
> floating point type and converted the result back to whatever it had to.
> Sure, I could do it myself, but having things like Log and Sqrt available
> for fixed and decimal types seems almost as fundamental as having "+" and
> "-". Its pretty basic to most math that is just a bit more complex than
> balancing my checkbook. (Maybe even there as well - you need Sqrt to compute
> interest, don't you? :-)
> 
> You're probably right about it being considered and rejected for Ada95.
> Maybe its time to reconsider?
> 
> Other extensions I think would be useful here would be vector and matrix
> math. That shows up often enough to be generally useful and there are
> already a number of packages available to do it. So it could be a case of
> standardizing on an existing library - if I dare bring that up! :-)
> 
> I'd also vote for statistics - partly because I think it would get used a
> lot and partly because I just like statistics. (A friend once described it
> this way: Statistics is to Math what The National Enquirer is to Journalism.
> :-)
> 
> Other languages provide some math capabilities, but generally don't go this
> far. That would make Ada even more useful in the math realm than it already
> is. And I don't think its a stretch too far from the beaten path to cover
> vectors, matricese and statistics. Those areas are used often enough that it
> wouldn't seem "strange" to support them.
> 
> 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/
> 
> 
> "FGD" <presbeis@look.ca> wrote in message news:3C22468C.30901@look.ca...
> 
>>
>>There is a range issue here, most of these functions will map out of the
>>range of the original type or will have unsatisfactory precision within
>>the original type--such extensions are generally useless. Converting to
>>float and using the float result is usually the best solution. For most
>>of the remaining cases converting back from float to the original type
>>is the most efficient way to compute the desired result. For the very
>>few remaining cases, the programer should be able to supply efficient
>>algorithms.
>>
>>I think all of this was considered when designing Ada95.
>>
>>
> 
> 
> 

Re: Math Libraries (was Re: Ada2005)

[Marin David Condic]

"FGD" <presbeis@look.ca> wrote in message news:3C236F94.7020101@look.ca...
>
> I agree that linear algebra types such as vector and matrix would be a
> nice language extension. These would benefit the most from hardware

I don't know that it needs to be a language extension. That starts asking
for something that is harder to do than simply providing a package and I
don't see an enormous amount of utility to it. Most Ada programmers would
probably easily comprehend and work with a package that defined "+" and so
on for a vector or matrix type so I think you could get the features (albeit
maybe not quite as cleanly) without forcing the compiler writers to make the
language itself more complex.

> extensions such as SIMD, and having them within the language would
> ensure that all target machines are exploited to their full potential.
>
Obviously, it would be advantageous for a compiler writer to take advantage
of any underlying hardware rather than rely strictly on Ada syntax to
implement the type. The nice thing about implementing it as a package is
that the body could be implementation dependent, but the spec could be
portable. If you've got the hardware, implement it in assembler.

>
> I'm not too sure about stats. Basic stats can be handled with linear
> algebra and elementary math. The problem is that it's not clear where to
> stop. It's something to think about...
>
I'm thinking that some packages to get you things like mean, variance,
standard deviation, etc., from arrays of various numeric types would be
enough - for now. :-) (I've got some packages that do this already - it
really isn't that hard to implement.) Sure, you could imagine all kinds of
wonerful sophistication that one might get from a true statistical package,
but why push our luck? Settle for some nice, basic statistics that let
people throw some analysis into their run-of-the-mill apps rather than shoot
for something that would satisfy the full-blown statisticians. It would
still be ahead of most other languages I'm aware of and wouldn't require
some major revision to the language syntax or semantics.

Just a thought....

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/

Re: Math Libraries (was Re: Ada2005)

[tmoran]

A long time ago my Ada compiler vendor included a NAG (Numerical
Analysis Group?) library.  It had most of this stuff.  Does it
still exist?

Re: Math Libraries (was Re: Ada2005)

[Marin David Condic]

That would be something interesting - if one or more vendors was already
supporting a math library that did linear-a and stats. (I'm assuming you
mean that this was a byproduct of some Ada interest group?) I'm in favor of
glomming onto any of the things that might already be semi-standards &
getting them more widely accepted.

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/


<tmoran@acm.org> wrote in message news:4fMU7.19924$Ah.630297@rwcrnsc52...
> A long time ago my Ada compiler vendor included a NAG (Numerical
> Analysis Group?) library.  It had most of this stuff.  Does it
> still exist?

Re: Math Libraries (was Re: Ada2005)

[Dan Nagle]

Hello,

Check at www.nag.co.uk to see if they support an Ada binding.

A quick check didn't show me anything about Ada, but you may be able
to use the Fortran or C bindings to gain access if NAG supports
a target compiler your Ada compiler supports.

-- 
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.

On Fri, 21 Dec 2001 19:40:48 GMT, tmoran@acm.org wrote:

>A long time ago my Ada compiler vendor included a NAG (Numerical
>Analysis Group?) library.  It had most of this stuff.  Does it
>still exist?

Re: Math Libraries (was Re: Ada2005)

[Eric Merritt]

--- Marin David Condic
<dont.bother.mcondic.auntie.spam@[acm.org>]>,
MISSING_MAILBOX_TERMINATOR@.SYNTAX-ERROR. wrote:
> "FGD" <presbeis@look.ca> wrote in message
> news:3C236F94.7020101@look.ca...
> >
> > I agree that linear algebra types such as vector
> and matrix would be a
> > nice language extension. These would benefit the
> most from hardware
> 
> I don't know that it needs to be a language
> extension. That starts asking
> for something that is harder to do than simply
> providing a package and I
> don't see an enormous amount of utility to it. Most
> Ada programmers would
> probably easily comprehend and work with a package
> that defined "+" and so
> on for a vector or matrix type so I think you could
> get the features (albeit
> maybe not quite as cleanly) without forcing the
> compiler writers to make the
> language itself more complex.
> 
Why not add this to the current ACL initiative.

__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com

Math Update for Ada 2005

[Steven Deller]

All the email about Math libraries reminded me of one of Ada 95's
shortcomings.

The IEEE math definitions have included NaN and Inf semantics for quite
some time. Many (if not all) native platforms and many embedded
platforms can support this.  I have run into C++ and C code that uses
these.  Ada 95 does NOT support these.

Interfacing Ada with C or C++ code that uses these can be quite a pain.

How could we add these semantics into Ada 2005 without breaking past
code and without *forcing* platforms to support this (if they don't do
so easily).

My thought was to have some sort of program wide values for floating
point (settable?), with appropriate attributes to query the settings.

Is that reasonable?

Does anyone else want these semantics available?

Suppose you have a subtype with narrow constraints (less than the 'Base
range).  Would Inf and NaN apply?  I believe it would.

I'd suggest that wherever raising constraint_error (for these types)
would occur, instead the values would be set directly to "Inf" or "NaN"
(consistent with IEEE semantics).  Basically, if 'Base includes Inf and
NaN values, then any subtype would include them as well.   Or more to
the point, any and all floating point types either would, or would not,
include the values Inf and NaN (and appropriate semantics).

Addition of these values would not require any additional constraint
checking beyond that which is done now.  Wherever code (without NaN and
Inf) would have done a constraint check:
  if val<low_bound then raise constraint_error
  if val>hi_bound then raise constraint_error

code (with NaN and Inf) would now be generated as
  if val /= NaN and val<low_bound then val := -Inf
  if val /= NaN and val>hi_bound then val := +Inf

I seem to recall (?) that the "two" predicates are really just one test
in IEEE arithmetic, i.e. I believe there is a way to check for something
being "commensurate" and then comparing values, so the resulting code
should not be any more complex or costly than current code. 

Typical application code could then look like:
  do lots of computations to compute one or more values
  if val = Inf then
    do things based on value going out of range
    including possibly explicitly raising constraint_error
  end if

  if val = NaN then
    ...

The state could even be settable (perhaps at execution startup).  In
that case, there would have to be a test for the state (to decide
whether to raise constraint_error or set a value to +/-Inf) though there
might be some clever load time operations that could eliminate that
test.

This model can simplify code in many situations.  When it is EXPECTED
that something may go out of range and "that is ok", then raising an
exception is not necessarily the right thing to do, particularly if the
computation code "consumes" some inputs.  The current Ada model *forces*
an application to either "consume all data before computing", wrap an
exception handler around every data "consumption", or have coupling
between code and one "overall" exception handler so the handler knows
how much data to "skip".   None of these may be as satisfactory as:
  loop
   get data
   compute some
   get more data
   compute some
   get more data
   compute some
   if NaN or Inf values then
     output something
   else
     output something else
   end if 
  end loop

Regards,
Steven Deller

Re: Math Update for Ada 2005

[Robert Dewar]

"Steven Deller" <deller@smsail.com> wrote in message news:<mailman.1009040342.32000.comp.lang.ada@ada.eu.org>...
> All the email about Math libraries reminded me of one of Ada 95's
> shortcomings.
> 
> The IEEE math definitions have included NaN and Inf semantics for quite
> some time. Many (if not all) native platforms and many embedded
> platforms can support this.  I have run into C++ and C code that uses
> these.  Ada 95 does NOT support these.

Ada 95 was carefully designed so that support can be
added for infinities and Nan's without in anyway violating
the RM semantics, and in fact GNAT does support the use of
Inf and Nan semantics in full generality, though it does
not provide all the IEEE facilities for manipulating such
values.

These facilities can be added with external packages. For
an *extensive* discussion of this entire issue see Sam
Figueroa's thesis (NYU, Robert Dewar thesis advisor). This
thesis addresses the entire issue of floating-point evaluation schemes
in high level languages from an IEEE
point of view, and specifically proposes a package and
other facilities (pragmas attributes etc) for full support
of the IEEE model in Ada 95 in an upwards compatible manner.

At least start from Sam's work, don't reinvent the wheel :-)

Re: Math Update for Ada 2005

[Brian Rogoff]

On 23 Dec 2001, Robert Dewar wrote:
> Ada 95 was carefully designed so that support can be
> added for infinities and Nan's without in anyway violating
> the RM semantics, and in fact GNAT does support the use of
> Inf and Nan semantics in full generality, though it does
> not provide all the IEEE facilities for manipulating such
> values.
>
> These facilities can be added with external packages. For
> an *extensive* discussion of this entire issue see Sam
> Figueroa's thesis (NYU, Robert Dewar thesis advisor). This
> thesis addresses the entire issue of floating-point evaluation schemes
> in high level languages from an IEEE
> point of view, and specifically proposes a package and
> other facilities (pragmas attributes etc) for full support
> of the IEEE model in Ada 95 in an upwards compatible manner.
>
> At least start from Sam's work, don't reinvent the wheel :-)


Excellent advice, thanks. I'll answer the next question for the clueless

http://www.cs.nyu.edu/csweb/Research/Theses/figueroa_sam.pdf

-- Brian

Re: Math Libraries (was Re: Ada2005)

[FGD]

I'm not completely for extending Ada to include new math types. As I 
stressed earlier such extensions would generally be useless for most 
people. The only possible exception I can see is linear algebra...

Marin David Condic wrote:

> "FGD" <presbeis@look.ca> wrote in message news:3C236F94.7020101@look.ca...
> 
>>I agree that linear algebra types such as vector and matrix would be a
>>nice language extension. These would benefit the most from hardware
>>
> 
> I don't know that it needs to be a language extension. That starts asking
> for something that is harder to do than simply providing a package and I
> don't see an enormous amount of utility to it. Most Ada programmers would
> probably easily comprehend and work with a package that defined "+" and so
> on for a vector or matrix type so I think you could get the features (albeit
> maybe not quite as cleanly) without forcing the compiler writers to make the
> language itself more complex.


The reason why I mentionned it as a language extension is that the 
"matrix type" is simply not efficient when represented as an array of 
coefficients. Having a language defined matrix type acting on vector 
types leaved the compiler writers free to use whatever internal 
representation they like.

>>extensions such as SIMD, and having them within the language would
>>ensure that all target machines are exploited to their full potential.
>>
>>
> Obviously, it would be advantageous for a compiler writer to take advantage
> of any underlying hardware rather than rely strictly on Ada syntax to
> implement the type. The nice thing about implementing it as a package is
> that the body could be implementation dependent, but the spec could be
> portable. If you've got the hardware, implement it in assembler.


Of course, that's what we currently do---in Ada and all other 
general-purpose languages. But one of the main advantages of Ada is low 
maintenace cost. I, for one, write and maintain a lot of such packages 
but almost all of my maintenance work goes into code that looks like:

    procedure Whatever ...
    begin
        case Machine is
        when Alpha_EV4 =>
             Asm(....
        when X86_Pentium_3 =>
             Asm(....
        when others =>
             ....
        end case;
    end Whatever;

For example, when Intel released the Pentum 4, I spent weeks rewrite and 
test asm code for relatively basic little things. I still have months to 
go writing and testing new code for the Itanium chip... and then the 
AMD-64... Sigh! :-(

For such code, Ada doesn't present any more advantages than any other 
language. Of course, that only leaves the burden of asm maintenance to 
compiler writers. Still having a few non-elementary types such as matrix 
and vector would make my life a lot simpler sometimes.

>>I'm not too sure about stats. Basic stats can be handled with linear
>>algebra and elementary math. The problem is that it's not clear where to
>>stop. It's something to think about...
>>
>>
> I'm thinking that some packages to get you things like mean, variance,
> standard deviation, etc., from arrays of various numeric types would be
> enough - for now. :-) (I've got some packages that do this already - it
> really isn't that hard to implement.) Sure, you could imagine all kinds of
> wonerful sophistication that one might get from a true statistical package,
> but why push our luck? Settle for some nice, basic statistics that let
> people throw some analysis into their run-of-the-mill apps rather than shoot
> for something that would satisfy the full-blown statisticians. It would
> still be ahead of most other languages I'm aware of and wouldn't require
> some major revision to the language syntax or semantics.


There are already lots of stuff out there to satisfy "full-blown" 
statisticians and mathematicians. Ada has no business there. We should 
focus on stuff that is useful to a great deal of people. As far as I can 
tell, linear algebra with all of its applications is the only branch of 
math which is useful to a great deal of people. BTW mean, variance and 
standard deviation are all linear algebra except maybe for a few square 
roots here and there.

-- Frank

Re: Math Libraries (was Re: Ada2005)

[Jacob Sparre Andersen]

FGD wrote:

> I agree that linear algebra types such as vector and matrix would be a
> nice language extension.

I would prefer that they were added as some extra packages,
and not as new basic types. There is no point in changing
the language itself, if the problem can be solved within the
current framework. It is trivial to implement a vector type
yourself (see http://jacob.sparre.dk/Ada/matematik/ for an
example). Matrices are a bit harder, if we want full compile
time checking of the dimensions of the matrices.

Jacob
-- 
I �vrigt mener jeg at det er uhensigtsm�ssigt at skrive
"pipes" om kanaler i en begynderbog om Unix.

RE: Math Libraries (was Re: Ada2005)

[Robert C. Leif, Ph.D.]

From: Bob Leif
To: Marin Condic et al.,
I agree; however, I believe that a decimal floating type should be created
or a work-around be provided to circumvent the static restrictions on type
decimal. I still wish to be able to specify the exponent at run-time.
PC performance has long since passed the point of needing to match the
numeric format to the machine instead of the human. For most commercial
uses, decimal numbers are a much better choice than binary numbers.

I might note than even in the computer aided design of mechanical systems,
decimal would be a better choice. I see errors in VISIO where a specified
one or two digit number, which ends in three zeros, becomes filled with
numeric characters. These numbers are sufficiently close to the value that
they do not materially change it. However, the provide absolutely bizarre
dimensions on a drawing and are a distraction.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Marin David Condic
Sent: Thursday, December 20, 2001 8:35 AM
To: comp.lang.ada@ada.eu.org
Subject: Math Libraries (was Re: Ada2005)


We have in Ada a useful package: Ada.Numerics.Generic_Elementary_Functions
that works fine for floating point types.

Is there any reason not to include in Ada200x similar packages for generic
fixed and decimal types? It seems we ought to be able to compute logarithms,
square roots, etc. for numeric types other than floating point types, eh?

Would there be any reason not to expand the math functions beyond what is
already there? Math is pretty cheap to implement when compared to some of
the other suggested extensions to the language and it would definitely be
attractive to a given audience that might currently still be relying on
Fortran. (See also the discussion elsewhere about standard libraries...)

What math functions (or math branches) would be most desirable to add to the
language by way of some packages under Ada.Numerics?

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/

Re: Math Libraries (was Re: Ada2005)

[Marin David Condic]

You are suggesting some version of specifying a "digits" clause but no
"delta"? Then presuming the underlying implementation is some version of
packed-decimal, performing effectively floating point math with some
arbitrary number of digits?

That I might put into the "Nice To Have" category, but I'm not sure the
language would need a new data type. There are packages that define big
number arithmetic & perhaps using some version of that would be a good place
to start to see how useful it might be. Creating a new numeric type could be
useful from a language standpoint since all the presumptions could be there
about math operations, etc. (A private type with math ops defined just
doesn't quite cut it - consider generics as an example) but I'd want some
evidence that there is some significant user base that needs it before
making it a language extension...

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/


"Robert C. Leif, Ph.D." <rleif@rleif.com> wrote in message
news:mailman.1008921920.25553.comp.lang.ada@ada.eu.org...
> From: Bob Leif
> To: Marin Condic et al.,
> I agree; however, I believe that a decimal floating type should be created
> or a work-around be provided to circumvent the static restrictions on type
> decimal. I still wish to be able to specify the exponent at run-time.
> PC performance has long since passed the point of needing to match the
> numeric format to the machine instead of the human. For most commercial
> uses, decimal numbers are a much better choice than binary numbers.
>