* Ada2005 @ 2002-12-17 7:15 Karel Miklav 2002-12-17 11:43 ` Ada2005 Peter Amey 2002-12-17 14:14 ` Ada2005 Ted Dennison 0 siblings, 2 replies; 67+ messages in thread From: Karel Miklav @ 2002-12-17 7:15 UTC (permalink / raw) Hello folks, I've seen Peter Hermann mentioning Ada2005 in his post, but can't google out anything. Ada community seems healthy; seeing it has plans for the future would make my decision to migrate easier. Regards, Karel Miklav ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2002-12-17 7:15 Ada2005 Karel Miklav @ 2002-12-17 11:43 ` Peter Amey 2002-12-17 15:11 ` Ada2005 Robert A Duff 2002-12-17 14:14 ` Ada2005 Ted Dennison 1 sibling, 1 reply; 67+ messages in thread From: Peter Amey @ 2002-12-17 11:43 UTC (permalink / raw) Karel Miklav wrote: > > Hello folks, > > I've seen Peter Hermann mentioning Ada2005 in his post, but can't google > out anything. Ada community seems healthy; seeing it has plans for the > future would make my decision to migrate easier. > Try googling "Ada 0y" or "Ada0y" instead of Ada2005. This is much the same way that 9x eventually became 95. Peter ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2002-12-17 11:43 ` Ada2005 Peter Amey @ 2002-12-17 15:11 ` Robert A Duff 0 siblings, 0 replies; 67+ messages in thread From: Robert A Duff @ 2002-12-17 15:11 UTC (permalink / raw) Peter Amey <peter.amey@praxis-cs.co.uk> writes: > Karel Miklav wrote: > > > > Hello folks, > > > > I've seen Peter Hermann mentioning Ada2005 in his post, but can't google > > out anything. Ada community seems healthy; seeing it has plans for the > > future would make my decision to migrate easier. > > > > Try googling "Ada 0y" or "Ada0y" instead of Ada2005. This is much the > same way that 9x eventually became 95. Or look at what the ARG is up to, especially "Amendment AI's". www.ada-auth.org - Bob ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2002-12-17 7:15 Ada2005 Karel Miklav 2002-12-17 11:43 ` Ada2005 Peter Amey @ 2002-12-17 14:14 ` Ted Dennison 2002-12-17 15:54 ` Ada2005 Peter Hermann 1 sibling, 1 reply; 67+ messages in thread From: Ted Dennison @ 2002-12-17 14:14 UTC (permalink / raw) Karel Miklav <karel@inetis.spppambait.com> wrote in message news:<haAL9.1646$tQ1.100403@news.siol.net>... > I've seen Peter Hermann mentioning Ada2005 in his post, but can't google > out anything. Ada community seems healthy; seeing it has plans for the That's funny. I use Google for my newsreader, and when I clicked on your message it came up as message 57 in the "Ada2005" thread. :-) ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2002-12-17 14:14 ` Ada2005 Ted Dennison @ 2002-12-17 15:54 ` Peter Hermann 2002-12-18 9:04 ` Ada2005 Anders Wirzenius 0 siblings, 1 reply; 67+ messages in thread From: Peter Hermann @ 2002-12-17 15:54 UTC (permalink / raw) Ted Dennison <dennison@telepath.com> wrote: > That's funny. I use Google for my newsreader, and when I clicked on > your message it came up as message 57 in the "Ada2005" thread. :-) I like Ada2005. This is a fine deadline for a small incremental useful enhancement for Ada which should come as soon as possible - but not sooner. (or later ;-) The ingredients are visible today. A name like Ada0y (y for "why") questions the project. -- --Peter Hermann(49)0711-685-3611 fax3758 ica2ph@csv.ica.uni-stuttgart.de --Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen --http://www.csv.ica.uni-stuttgart.de/homes/ph/ --Team Ada: "C'mon people let the world begin" (Paul McCartney) ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2002-12-17 15:54 ` Ada2005 Peter Hermann @ 2002-12-18 9:04 ` Anders Wirzenius 2002-12-18 14:48 ` Ada2005 Ted Dennison 0 siblings, 1 reply; 67+ messages in thread From: Anders Wirzenius @ 2002-12-18 9:04 UTC (permalink / raw) "Peter Hermann" <ica2ph@iris16.csv.ica.uni-stuttgart.de> wrote in message news:atnhc0$2a3$1@news.uni-stuttgart.de... > > A name like Ada0y (y for "why") questions the project. > Ada0y associates Finnish-speaking people to a company named Ada Oy, where Oy stands for incorporated or limited (Ada ltd). That may lead people to get the impression that the Ada language is "owned" by some company and not one of the least commercial connected programming languages. Anders ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2002-12-18 9:04 ` Ada2005 Anders Wirzenius @ 2002-12-18 14:48 ` Ted Dennison 2002-12-19 9:01 ` Ada2005 Anders Wirzenius 0 siblings, 1 reply; 67+ messages in thread From: Ted Dennison @ 2002-12-18 14:48 UTC (permalink / raw) "Anders Wirzenius" <anders.wirzenius@pp.qnet.fi> wrote in message news:<FSWL9.87$6U2.84@read3.inet.fi>... > "Peter Hermann" <ica2ph@iris16.csv.ica.uni-stuttgart.de> wrote in message news:atnhc0$2a3$1@news.uni-stuttgart.de... > > > > A name like Ada0y (y for "why") questions the project. > > > > Ada0y associates Finnish-speaking people to a company named Ada Oy, where Oy If it associates with being finnished, that can't be a bad thing. Wait...put down the bats...I'm sorr..ow!ow! ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2002-12-18 14:48 ` Ada2005 Ted Dennison @ 2002-12-19 9:01 ` Anders Wirzenius 0 siblings, 0 replies; 67+ messages in thread From: Anders Wirzenius @ 2002-12-19 9:01 UTC (permalink / raw) "Ted Dennison" <dennison@telepath.com> wrote in message news:4519e058.0212180648.3f5fac67@posting.google.com... > "Anders Wirzenius" <anders.wirzenius@pp.qnet.fi> wrote in message news:<FSWL9.87$6U2.84@read3.inet.fi>... > > > > Ada0y associates Finnish-speaking people to a company named Ada Oy, where Oy > > If it associates with being finnished, that can't be a bad thing. > > > Wait...put down the bats...I'm sorr..ow!ow! I can imagine the bats are from Sweden ;-) ^ permalink raw reply [flat|nested] 67+ messages in thread
* Ada2005 @ 2005-03-24 14:36 Szymon Guz 2005-03-24 15:30 ` Ada2005 Xaelis 2005-03-24 15:32 ` Ada2005 Larry Kilgallen 0 siblings, 2 replies; 67+ messages in thread From: Szymon Guz @ 2005-03-24 14:36 UTC (permalink / raw) Hi is there any compiler for Ada2005 available ? regards Szymon Guz ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2005-03-24 14:36 Ada2005 Szymon Guz @ 2005-03-24 15:30 ` Xaelis 2005-03-24 15:32 ` Ada2005 Larry Kilgallen 1 sibling, 0 replies; 67+ messages in thread From: Xaelis @ 2005-03-24 15:30 UTC (permalink / raw) Hi, On Thu, 2005-03-24 at 15:36 +0100, Szymon Guz wrote: > is there any compiler for Ada2005 available ? Yes, the cvs gcc version (4.X) works (not fully Ada 2005 compliant but already lot of stuff). You can use a snapshot available here : http://gcc.gnu.org/snapshots.html regards -- Alexis Muller Laboratoire d'Informatique Fondamentale de Lille (LIFL) Universite de Lille 1 - 59655 Villeneuve d'Ascq Cedex Web : http://www.lifl.fr/~mullera ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2005-03-24 14:36 Ada2005 Szymon Guz 2005-03-24 15:30 ` Ada2005 Xaelis @ 2005-03-24 15:32 ` Larry Kilgallen 1 sibling, 0 replies; 67+ messages in thread From: Larry Kilgallen @ 2005-03-24 15:32 UTC (permalink / raw) In article <d1uj8i$v9f$1@news2.ipartners.pl>, Szymon Guz <guzo@stud.ics.p.lodz.pl> writes: > is there any compiler for Ada2005 available ? That would not be possible (except for advances in the physics of time travel) because Ada2005 has not been finally defined as yet. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 @ 2001-12-12 14:05 Peter Hermann 0 siblings, 0 replies; 67+ messages in thread From: Peter Hermann @ 2001-12-12 14:05 UTC (permalink / raw) -- --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) ^ permalink raw reply [flat|nested] 67+ messages in thread
* Ada2005 @ 2001-12-11 9:33 Peter Hermann 2001-12-11 11:05 ` Ada2005 M. A. Alves ` (5 more replies) 0 siblings, 6 replies; 67+ messages in thread From: Peter Hermann @ 2001-12-11 9:33 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-11 9:33 Ada2005 Peter Hermann @ 2001-12-11 11:05 ` M. A. Alves 2001-12-11 11:55 ` Ada2005 Aaro Koskinen 2001-12-11 11:23 ` Ada2005 Martin Dowie ` (4 subsequent siblings) 5 siblings, 1 reply; 67+ messages in thread From: M. A. Alves @ 2001-12-11 11:05 UTC (permalink / raw) To: comp.lang.ada > 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-11 11:05 ` Ada2005 M. A. Alves @ 2001-12-11 11:55 ` Aaro Koskinen 2001-12-11 14:49 ` Ada2005 Wes Groleau 2001-12-11 14:58 ` Ada2005 Marin David Condic 0 siblings, 2 replies; 67+ messages in thread From: Aaro Koskinen @ 2001-12-11 11:55 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-11 11:55 ` Ada2005 Aaro Koskinen @ 2001-12-11 14:49 ` Wes Groleau 2001-12-11 14:58 ` Ada2005 Marin David Condic 1 sibling, 0 replies; 67+ messages in thread From: Wes Groleau @ 2001-12-11 14:49 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-11 11:55 ` Ada2005 Aaro Koskinen 2001-12-11 14:49 ` Ada2005 Wes Groleau @ 2001-12-11 14:58 ` Marin David Condic 2001-12-11 15:18 ` Ada2005 Ted Dennison 2001-12-12 8:37 ` Ada2005 Alfred Hilscher 1 sibling, 2 replies; 67+ messages in thread From: Marin David Condic @ 2001-12-11 14:58 UTC (permalink / raw) 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". > ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-11 14:58 ` Ada2005 Marin David Condic @ 2001-12-11 15:18 ` Ted Dennison 2001-12-12 8:37 ` Ada2005 Alfred Hilscher 1 sibling, 0 replies; 67+ messages in thread From: Ted Dennison @ 2001-12-11 15:18 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-11 14:58 ` Ada2005 Marin David Condic 2001-12-11 15:18 ` Ada2005 Ted Dennison @ 2001-12-12 8:37 ` Alfred Hilscher 1 sibling, 0 replies; 67+ messages in thread From: Alfred Hilscher @ 2001-12-12 8:37 UTC (permalink / raw) 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". > > ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-11 9:33 Ada2005 Peter Hermann 2001-12-11 11:05 ` Ada2005 M. A. Alves @ 2001-12-11 11:23 ` Martin Dowie 2001-12-11 11:54 ` Ada2005 Preben Randhol ` (3 subsequent siblings) 5 siblings, 0 replies; 67+ messages in thread From: Martin Dowie @ 2001-12-11 11:23 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-11 9:33 Ada2005 Peter Hermann 2001-12-11 11:05 ` Ada2005 M. A. Alves 2001-12-11 11:23 ` Ada2005 Martin Dowie @ 2001-12-11 11:54 ` Preben Randhol 2001-12-11 12:06 ` Ada2005 Larry Kilgallen ` (2 subsequent siblings) 5 siblings, 0 replies; 67+ messages in thread From: Preben Randhol @ 2001-12-11 11:54 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-11 9:33 Ada2005 Peter Hermann ` (2 preceding siblings ...) 2001-12-11 11:54 ` Ada2005 Preben Randhol @ 2001-12-11 12:06 ` Larry Kilgallen 2001-12-11 14:39 ` Ada2005 Ted Dennison 2001-12-12 11:29 ` Ada2005 Peter Hermann 5 siblings, 0 replies; 67+ messages in thread From: Larry Kilgallen @ 2001-12-11 12:06 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-11 9:33 Ada2005 Peter Hermann ` (3 preceding siblings ...) 2001-12-11 12:06 ` Ada2005 Larry Kilgallen @ 2001-12-11 14:39 ` Ted Dennison 2001-12-12 4:39 ` Ada2005 Jeffrey Carter 2001-12-13 18:39 ` Ada2005 Randy Brukardt 2001-12-12 11:29 ` Ada2005 Peter Hermann 5 siblings, 2 replies; 67+ messages in thread From: Ted Dennison @ 2001-12-11 14:39 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-11 14:39 ` Ada2005 Ted Dennison @ 2001-12-12 4:39 ` Jeffrey Carter 2001-12-13 18:39 ` Ada2005 Randy Brukardt 1 sibling, 0 replies; 67+ messages in thread From: Jeffrey Carter @ 2001-12-12 4:39 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-11 14:39 ` Ada2005 Ted Dennison 2001-12-12 4:39 ` Ada2005 Jeffrey Carter @ 2001-12-13 18:39 ` Randy Brukardt 1 sibling, 0 replies; 67+ messages in thread From: Randy Brukardt @ 2001-12-13 18:39 UTC (permalink / raw) (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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-11 9:33 Ada2005 Peter Hermann ` (4 preceding siblings ...) 2001-12-11 14:39 ` Ada2005 Ted Dennison @ 2001-12-12 11:29 ` Peter Hermann 2001-12-12 12:42 ` Ada2005 Larry Kilgallen ` (2 more replies) 5 siblings, 3 replies; 67+ messages in thread From: Peter Hermann @ 2001-12-12 11:29 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-12 11:29 ` Ada2005 Peter Hermann @ 2001-12-12 12:42 ` Larry Kilgallen 2001-12-12 12:51 ` Ada2005 Martin Dowie 2001-12-12 12:59 ` Ada2005 Carsten Freining 2 siblings, 0 replies; 67+ messages in thread From: Larry Kilgallen @ 2001-12-12 12:42 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-12 11:29 ` Ada2005 Peter Hermann 2001-12-12 12:42 ` Ada2005 Larry Kilgallen @ 2001-12-12 12:51 ` Martin Dowie 2001-12-12 12:59 ` Ada2005 Carsten Freining 2 siblings, 0 replies; 67+ messages in thread From: Martin Dowie @ 2001-12-12 12:51 UTC (permalink / raw) "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... ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-12 11:29 ` Ada2005 Peter Hermann 2001-12-12 12:42 ` Ada2005 Larry Kilgallen 2001-12-12 12:51 ` Ada2005 Martin Dowie @ 2001-12-12 12:59 ` Carsten Freining 2001-12-12 14:40 ` Ada2005 Peter Hermann ` (2 more replies) 2 siblings, 3 replies; 67+ messages in thread From: Carsten Freining @ 2001-12-12 12:59 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-12 12:59 ` Ada2005 Carsten Freining @ 2001-12-12 14:40 ` Peter Hermann 2001-12-12 15:16 ` Ada2005 Ted Dennison 2001-12-14 4:40 ` Ada2005 Patrick Hohmeyer 2001-12-12 18:04 ` Ada2005 Mark Lundquist 2001-12-13 18:13 ` Ada2005 Georg Bauhaus 2 siblings, 2 replies; 67+ messages in thread From: Peter Hermann @ 2001-12-12 14:40 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-12 14:40 ` Ada2005 Peter Hermann @ 2001-12-12 15:16 ` Ted Dennison 2001-12-12 15:37 ` Ada2005 Larry Kilgallen ` (3 more replies) 2001-12-14 4:40 ` Ada2005 Patrick Hohmeyer 1 sibling, 4 replies; 67+ messages in thread From: Ted Dennison @ 2001-12-12 15:16 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-12 15:16 ` Ada2005 Ted Dennison @ 2001-12-12 15:37 ` Larry Kilgallen 2001-12-12 17:49 ` Ada2005 Ted Dennison 2001-12-12 18:02 ` Ada2005 tmoran ` (2 subsequent siblings) 3 siblings, 1 reply; 67+ messages in thread From: Larry Kilgallen @ 2001-12-12 15:37 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-12 15:37 ` Ada2005 Larry Kilgallen @ 2001-12-12 17:49 ` Ted Dennison 0 siblings, 0 replies; 67+ messages in thread From: Ted Dennison @ 2001-12-12 17:49 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-12 15:16 ` Ada2005 Ted Dennison 2001-12-12 15:37 ` Ada2005 Larry Kilgallen @ 2001-12-12 18:02 ` tmoran 2001-12-12 18:17 ` Ada2005 Ted Dennison 2001-12-12 18:14 ` Ada2005 Mark Lundquist 2001-12-13 20:07 ` Ada2005 Ted Dennison 3 siblings, 1 reply; 67+ messages in thread From: tmoran @ 2001-12-12 18:02 UTC (permalink / raw) > >> 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-12 18:02 ` Ada2005 tmoran @ 2001-12-12 18:17 ` Ted Dennison 2001-12-12 18:31 ` Ada2005 Sergey Koshcheyev 0 siblings, 1 reply; 67+ messages in thread From: Ted Dennison @ 2001-12-12 18:17 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-12 18:17 ` Ada2005 Ted Dennison @ 2001-12-12 18:31 ` Sergey Koshcheyev 2001-12-12 19:08 ` Ada2005 Ted Dennison 0 siblings, 1 reply; 67+ messages in thread From: Sergey Koshcheyev @ 2001-12-12 18:31 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-12 18:31 ` Ada2005 Sergey Koshcheyev @ 2001-12-12 19:08 ` Ted Dennison 0 siblings, 0 replies; 67+ messages in thread From: Ted Dennison @ 2001-12-12 19:08 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-12 15:16 ` Ada2005 Ted Dennison 2001-12-12 15:37 ` Ada2005 Larry Kilgallen 2001-12-12 18:02 ` Ada2005 tmoran @ 2001-12-12 18:14 ` Mark Lundquist 2001-12-12 18:40 ` Ada2005 Ted Dennison 2001-12-13 20:07 ` Ada2005 Ted Dennison 3 siblings, 1 reply; 67+ messages in thread From: Mark Lundquist @ 2001-12-12 18:14 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-12 18:14 ` Ada2005 Mark Lundquist @ 2001-12-12 18:40 ` Ted Dennison 2001-12-12 19:12 ` Ada2005 Mark Lundquist 0 siblings, 1 reply; 67+ messages in thread From: Ted Dennison @ 2001-12-12 18:40 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-12 18:40 ` Ada2005 Ted Dennison @ 2001-12-12 19:12 ` Mark Lundquist 2001-12-12 19:41 ` Ada2005 Ted Dennison 0 siblings, 1 reply; 67+ messages in thread From: Mark Lundquist @ 2001-12-12 19:12 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-12 19:12 ` Ada2005 Mark Lundquist @ 2001-12-12 19:41 ` Ted Dennison 0 siblings, 0 replies; 67+ messages in thread From: Ted Dennison @ 2001-12-12 19:41 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-12 15:16 ` Ada2005 Ted Dennison ` (2 preceding siblings ...) 2001-12-12 18:14 ` Ada2005 Mark Lundquist @ 2001-12-13 20:07 ` Ted Dennison 3 siblings, 0 replies; 67+ messages in thread From: Ted Dennison @ 2001-12-13 20:07 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-12 14:40 ` Ada2005 Peter Hermann 2001-12-12 15:16 ` Ada2005 Ted Dennison @ 2001-12-14 4:40 ` Patrick Hohmeyer 2001-12-14 9:55 ` Ada2005 Lutz Donnerhacke ` (2 more replies) 1 sibling, 3 replies; 67+ messages in thread From: Patrick Hohmeyer @ 2001-12-14 4:40 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-14 4:40 ` Ada2005 Patrick Hohmeyer @ 2001-12-14 9:55 ` Lutz Donnerhacke 2001-12-14 10:36 ` Ada2005 Dmitry A. Kazakov 2001-12-17 18:40 ` Ada2005 Matthew Heaney 2 siblings, 0 replies; 67+ messages in thread From: Lutz Donnerhacke @ 2001-12-14 9:55 UTC (permalink / raw) * 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-14 4:40 ` Ada2005 Patrick Hohmeyer 2001-12-14 9:55 ` Ada2005 Lutz Donnerhacke @ 2001-12-14 10:36 ` Dmitry A. Kazakov 2001-12-17 18:40 ` Ada2005 Matthew Heaney 2 siblings, 0 replies; 67+ messages in thread From: Dmitry A. Kazakov @ 2001-12-14 10:36 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-14 4:40 ` Ada2005 Patrick Hohmeyer 2001-12-14 9:55 ` Ada2005 Lutz Donnerhacke 2001-12-14 10:36 ` Ada2005 Dmitry A. Kazakov @ 2001-12-17 18:40 ` Matthew Heaney 2 siblings, 0 replies; 67+ messages in thread From: Matthew Heaney @ 2001-12-17 18:40 UTC (permalink / raw) "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; ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-12 12:59 ` Ada2005 Carsten Freining 2001-12-12 14:40 ` Ada2005 Peter Hermann @ 2001-12-12 18:04 ` Mark Lundquist 2001-12-12 21:25 ` Ada2005 Mark Lundquist ` (2 more replies) 2001-12-13 18:13 ` Ada2005 Georg Bauhaus 2 siblings, 3 replies; 67+ messages in thread From: Mark Lundquist @ 2001-12-12 18:04 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-12 18:04 ` Ada2005 Mark Lundquist @ 2001-12-12 21:25 ` Mark Lundquist 2001-12-13 18:40 ` Ada2005 Stephen Leake 2001-12-13 9:11 ` Ada2005 Dmitry A. Kazakov 2001-12-20 11:24 ` Ada2005 Carsten Freining 2 siblings, 1 reply; 67+ messages in thread From: Mark Lundquist @ 2001-12-12 21:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-12 21:25 ` Ada2005 Mark Lundquist @ 2001-12-13 18:40 ` Stephen Leake 2001-12-13 19:01 ` Ada2005 Mark Lundquist 0 siblings, 1 reply; 67+ messages in thread From: Stephen Leake @ 2001-12-13 18:40 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-13 18:40 ` Ada2005 Stephen Leake @ 2001-12-13 19:01 ` Mark Lundquist 2001-12-14 17:17 ` Ada2005 Stephen Leake 0 siblings, 1 reply; 67+ messages in thread From: Mark Lundquist @ 2001-12-13 19:01 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-13 19:01 ` Ada2005 Mark Lundquist @ 2001-12-14 17:17 ` Stephen Leake 0 siblings, 0 replies; 67+ messages in thread From: Stephen Leake @ 2001-12-14 17:17 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-12 18:04 ` Ada2005 Mark Lundquist 2001-12-12 21:25 ` Ada2005 Mark Lundquist @ 2001-12-13 9:11 ` Dmitry A. Kazakov 2001-12-17 17:50 ` Ada2005 Ray Blaak 2001-12-20 11:24 ` Ada2005 Carsten Freining 2 siblings, 1 reply; 67+ messages in thread From: Dmitry A. Kazakov @ 2001-12-13 9:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-13 9:11 ` Ada2005 Dmitry A. Kazakov @ 2001-12-17 17:50 ` Ray Blaak 2001-12-18 11:55 ` Ada2005 Dmitry A. Kazakov 2001-12-19 18:20 ` Ada2005 Mark Lundquist 0 siblings, 2 replies; 67+ messages in thread From: Ray Blaak @ 2001-12-17 17:50 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-17 17:50 ` Ada2005 Ray Blaak @ 2001-12-18 11:55 ` Dmitry A. Kazakov 2001-12-18 19:51 ` Ada2005 Ray Blaak 2001-12-19 18:20 ` Ada2005 Mark Lundquist 1 sibling, 1 reply; 67+ messages in thread From: Dmitry A. Kazakov @ 2001-12-18 11:55 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-18 11:55 ` Ada2005 Dmitry A. Kazakov @ 2001-12-18 19:51 ` Ray Blaak 2001-12-19 8:34 ` Ada2005 Dmitry A. Kazakov 0 siblings, 1 reply; 67+ messages in thread From: Ray Blaak @ 2001-12-18 19:51 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-18 19:51 ` Ada2005 Ray Blaak @ 2001-12-19 8:34 ` Dmitry A. Kazakov 2001-12-19 13:30 ` Ada2005 Mark Lundquist 2001-12-19 18:23 ` Ada2005 Ray Blaak 0 siblings, 2 replies; 67+ messages in thread From: Dmitry A. Kazakov @ 2001-12-19 8:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-19 8:34 ` Ada2005 Dmitry A. Kazakov @ 2001-12-19 13:30 ` Mark Lundquist 2001-12-19 18:23 ` Ada2005 Ray Blaak 1 sibling, 0 replies; 67+ messages in thread From: Mark Lundquist @ 2001-12-19 13:30 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-19 8:34 ` Ada2005 Dmitry A. Kazakov 2001-12-19 13:30 ` Ada2005 Mark Lundquist @ 2001-12-19 18:23 ` Ray Blaak 1 sibling, 0 replies; 67+ messages in thread From: Ray Blaak @ 2001-12-19 18:23 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-17 17:50 ` Ada2005 Ray Blaak 2001-12-18 11:55 ` Ada2005 Dmitry A. Kazakov @ 2001-12-19 18:20 ` Mark Lundquist 2001-12-19 19:19 ` Ada2005 Ray Blaak 2001-12-20 14:17 ` Ada2005 Dmitry A. Kazakov 1 sibling, 2 replies; 67+ messages in thread From: Mark Lundquist @ 2001-12-19 18:20 UTC (permalink / raw) "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? ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-19 18:20 ` Ada2005 Mark Lundquist @ 2001-12-19 19:19 ` Ray Blaak 2001-12-20 14:17 ` Ada2005 Dmitry A. Kazakov 1 sibling, 0 replies; 67+ messages in thread From: Ray Blaak @ 2001-12-19 19:19 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-19 18:20 ` Ada2005 Mark Lundquist 2001-12-19 19:19 ` Ada2005 Ray Blaak @ 2001-12-20 14:17 ` Dmitry A. Kazakov 1 sibling, 0 replies; 67+ messages in thread From: Dmitry A. Kazakov @ 2001-12-20 14:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-12 18:04 ` Ada2005 Mark Lundquist 2001-12-12 21:25 ` Ada2005 Mark Lundquist 2001-12-13 9:11 ` Ada2005 Dmitry A. Kazakov @ 2001-12-20 11:24 ` Carsten Freining 2001-12-20 14:27 ` Ada2005 Mark Lundquist ` (2 more replies) 2 siblings, 3 replies; 67+ messages in thread From: Carsten Freining @ 2001-12-20 11:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-20 11:24 ` Ada2005 Carsten Freining @ 2001-12-20 14:27 ` Mark Lundquist 2001-12-20 15:01 ` Ada2005 Matthew Woodcraft 2001-12-20 15:45 ` Ada2005 Mark Lundquist 2 siblings, 0 replies; 67+ messages in thread From: Mark Lundquist @ 2001-12-20 14:27 UTC (permalink / raw) [-- 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 > ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-20 11:24 ` Ada2005 Carsten Freining 2001-12-20 14:27 ` Ada2005 Mark Lundquist @ 2001-12-20 15:01 ` Matthew Woodcraft 2001-12-20 15:45 ` Ada2005 Mark Lundquist 2 siblings, 0 replies; 67+ messages in thread From: Matthew Woodcraft @ 2001-12-20 15:01 UTC (permalink / raw) 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- ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-20 11:24 ` Ada2005 Carsten Freining 2001-12-20 14:27 ` Ada2005 Mark Lundquist 2001-12-20 15:01 ` Ada2005 Matthew Woodcraft @ 2001-12-20 15:45 ` Mark Lundquist 2001-12-20 16:20 ` Ada2005 Mark Lundquist 2 siblings, 1 reply; 67+ messages in thread From: Mark Lundquist @ 2001-12-20 15:45 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-20 15:45 ` Ada2005 Mark Lundquist @ 2001-12-20 16:20 ` Mark Lundquist 0 siblings, 0 replies; 67+ messages in thread From: Mark Lundquist @ 2001-12-20 16:20 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Ada2005 2001-12-12 12:59 ` Ada2005 Carsten Freining 2001-12-12 14:40 ` Ada2005 Peter Hermann 2001-12-12 18:04 ` Ada2005 Mark Lundquist @ 2001-12-13 18:13 ` Georg Bauhaus 2 siblings, 0 replies; 67+ messages in thread From: Georg Bauhaus @ 2001-12-13 18:13 UTC (permalink / raw) 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.>) ^ permalink raw reply [flat|nested] 67+ messages in thread
end of thread, other threads:[~2005-03-24 15:32 UTC | newest] Thread overview: 67+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-12-17 7:15 Ada2005 Karel Miklav 2002-12-17 11:43 ` Ada2005 Peter Amey 2002-12-17 15:11 ` Ada2005 Robert A Duff 2002-12-17 14:14 ` Ada2005 Ted Dennison 2002-12-17 15:54 ` Ada2005 Peter Hermann 2002-12-18 9:04 ` Ada2005 Anders Wirzenius 2002-12-18 14:48 ` Ada2005 Ted Dennison 2002-12-19 9:01 ` Ada2005 Anders Wirzenius -- strict thread matches above, loose matches on Subject: below -- 2005-03-24 14:36 Ada2005 Szymon Guz 2005-03-24 15:30 ` Ada2005 Xaelis 2005-03-24 15:32 ` Ada2005 Larry Kilgallen 2001-12-12 14:05 Ada2005 Peter Hermann 2001-12-11 9:33 Ada2005 Peter Hermann 2001-12-11 11:05 ` Ada2005 M. A. Alves 2001-12-11 11:55 ` Ada2005 Aaro Koskinen 2001-12-11 14:49 ` Ada2005 Wes Groleau 2001-12-11 14:58 ` Ada2005 Marin David Condic 2001-12-11 15:18 ` Ada2005 Ted Dennison 2001-12-12 8:37 ` Ada2005 Alfred Hilscher 2001-12-11 11:23 ` Ada2005 Martin Dowie 2001-12-11 11:54 ` Ada2005 Preben Randhol 2001-12-11 12:06 ` Ada2005 Larry Kilgallen 2001-12-11 14:39 ` Ada2005 Ted Dennison 2001-12-12 4:39 ` Ada2005 Jeffrey Carter 2001-12-13 18:39 ` Ada2005 Randy Brukardt 2001-12-12 11:29 ` Ada2005 Peter Hermann 2001-12-12 12:42 ` Ada2005 Larry Kilgallen 2001-12-12 12:51 ` Ada2005 Martin Dowie 2001-12-12 12:59 ` Ada2005 Carsten Freining 2001-12-12 14:40 ` Ada2005 Peter Hermann 2001-12-12 15:16 ` Ada2005 Ted Dennison 2001-12-12 15:37 ` Ada2005 Larry Kilgallen 2001-12-12 17:49 ` Ada2005 Ted Dennison 2001-12-12 18:02 ` Ada2005 tmoran 2001-12-12 18:17 ` Ada2005 Ted Dennison 2001-12-12 18:31 ` Ada2005 Sergey Koshcheyev 2001-12-12 19:08 ` Ada2005 Ted Dennison 2001-12-12 18:14 ` Ada2005 Mark Lundquist 2001-12-12 18:40 ` Ada2005 Ted Dennison 2001-12-12 19:12 ` Ada2005 Mark Lundquist 2001-12-12 19:41 ` Ada2005 Ted Dennison 2001-12-13 20:07 ` Ada2005 Ted Dennison 2001-12-14 4:40 ` Ada2005 Patrick Hohmeyer 2001-12-14 9:55 ` Ada2005 Lutz Donnerhacke 2001-12-14 10:36 ` Ada2005 Dmitry A. Kazakov 2001-12-17 18:40 ` Ada2005 Matthew Heaney 2001-12-12 18:04 ` Ada2005 Mark Lundquist 2001-12-12 21:25 ` Ada2005 Mark Lundquist 2001-12-13 18:40 ` Ada2005 Stephen Leake 2001-12-13 19:01 ` Ada2005 Mark Lundquist 2001-12-14 17:17 ` Ada2005 Stephen Leake 2001-12-13 9:11 ` Ada2005 Dmitry A. Kazakov 2001-12-17 17:50 ` Ada2005 Ray Blaak 2001-12-18 11:55 ` Ada2005 Dmitry A. Kazakov 2001-12-18 19:51 ` Ada2005 Ray Blaak 2001-12-19 8:34 ` Ada2005 Dmitry A. Kazakov 2001-12-19 13:30 ` Ada2005 Mark Lundquist 2001-12-19 18:23 ` Ada2005 Ray Blaak 2001-12-19 18:20 ` Ada2005 Mark Lundquist 2001-12-19 19:19 ` Ada2005 Ray Blaak 2001-12-20 14:17 ` Ada2005 Dmitry A. Kazakov 2001-12-20 11:24 ` Ada2005 Carsten Freining 2001-12-20 14:27 ` Ada2005 Mark Lundquist 2001-12-20 15:01 ` Ada2005 Matthew Woodcraft 2001-12-20 15:45 ` Ada2005 Mark Lundquist 2001-12-20 16:20 ` Ada2005 Mark Lundquist 2001-12-13 18:13 ` Ada2005 Georg Bauhaus
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox