* Ada2005 @ 2001-12-11 9:33 Peter Hermann 2001-12-11 11:05 ` Ada2005 M. A. Alves ` (6 more replies) 0 siblings, 7 replies; 83+ 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] 83+ 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 ` (5 subsequent siblings) 6 siblings, 1 reply; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ 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 ` (4 subsequent siblings) 6 siblings, 0 replies; 83+ 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] 83+ 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 ` (3 subsequent siblings) 6 siblings, 0 replies; 83+ 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] 83+ 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 ` (2 subsequent siblings) 6 siblings, 0 replies; 83+ 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] 83+ 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 2001-12-20 16:34 ` Math Libraries (was Re: Ada2005) Marin David Condic 6 siblings, 2 replies; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ 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) 2001-12-20 16:34 ` Math Libraries (was Re: Ada2005) Marin David Condic 6 siblings, 3 replies; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ messages in thread
* Re: Ada2005 2001-12-12 15:37 ` Ada2005 Larry Kilgallen @ 2001-12-12 17:49 ` Ted Dennison 0 siblings, 0 replies; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ messages in thread
* Re: Ada2005 2001-12-12 18:31 ` Ada2005 Sergey Koshcheyev @ 2001-12-12 19:08 ` Ted Dennison 0 siblings, 0 replies; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ messages in thread
* Re: Ada2005 2001-12-12 19:12 ` Ada2005 Mark Lundquist @ 2001-12-12 19:41 ` Ted Dennison 0 siblings, 0 replies; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ messages in thread
* Re: Ada2005 2001-12-13 19:01 ` Ada2005 Mark Lundquist @ 2001-12-14 17:17 ` Stephen Leake 0 siblings, 0 replies; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ messages in thread
* Re: Ada2005 2001-12-20 15:45 ` Ada2005 Mark Lundquist @ 2001-12-20 16:20 ` Mark Lundquist 0 siblings, 0 replies; 83+ 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] 83+ 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; 83+ 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] 83+ messages in thread
* Math Libraries (was Re: Ada2005) 2001-12-11 9:33 Ada2005 Peter Hermann ` (5 preceding siblings ...) 2001-12-12 11:29 ` Ada2005 Peter Hermann @ 2001-12-20 16:34 ` Marin David Condic 2001-12-20 20:14 ` FGD 2001-12-20 23:20 ` Robert C. Leif, Ph.D. 6 siblings, 2 replies; 83+ messages in thread From: Marin David Condic @ 2001-12-20 16:34 UTC (permalink / raw) We have in Ada a useful package: Ada.Numerics.Generic_Elementary_Functions that works fine for floating point types. Is there any reason not to include in Ada200x similar packages for generic fixed and decimal types? It seems we ought to be able to compute logarithms, square roots, etc. for numeric types other than floating point types, eh? Would there be any reason not to expand the math functions beyond what is already there? Math is pretty cheap to implement when compared to some of the other suggested extensions to the language and it would definitely be attractive to a given audience that might currently still be relying on Fortran. (See also the discussion elsewhere about standard libraries...) What math functions (or math branches) would be most desirable to add to the language by way of some packages under Ada.Numerics? MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Math Libraries (was Re: Ada2005) 2001-12-20 16:34 ` Math Libraries (was Re: Ada2005) Marin David Condic @ 2001-12-20 20:14 ` FGD 2001-12-20 20:34 ` Marin David Condic 2001-12-20 23:20 ` Robert C. Leif, Ph.D. 1 sibling, 1 reply; 83+ messages in thread From: FGD @ 2001-12-20 20:14 UTC (permalink / raw) Marin David Condic wrote: > We have in Ada a useful package: Ada.Numerics.Generic_Elementary_Functions > that works fine for floating point types. > > Is there any reason not to include in Ada200x similar packages for generic > fixed and decimal types? It seems we ought to be able to compute logarithms, > square roots, etc. for numeric types other than floating point types, eh? There is a range issue here, most of these functions will map out of the range of the original type or will have unsatisfactory precision within the original type--such extensions are generally useless. Converting to float and using the float result is usually the best solution. For most of the remaining cases converting back from float to the original type is the most efficient way to compute the desired result. For the very few remaining cases, the programer should be able to supply efficient algorithms. I think all of this was considered when designing Ada95. > Would there be any reason not to expand the math functions beyond what is > already there? Math is pretty cheap to implement when compared to some of > the other suggested extensions to the language and it would definitely be > attractive to a given audience that might currently still be relying on > Fortran. (See also the discussion elsewhere about standard libraries...) > > What math functions (or math branches) would be most desirable to add to the > language by way of some packages under Ada.Numerics? One thing I like about Ada.Numerics is that, with the exception of random numbers, it contains only functions which are commonly implemented directly in hardware or nearly so. I like this RIS approach---and I would like future extensions to adhere to this philosophy. (Although the use of the word "Elementary" could be used to distinguish extensions which do.) Should the numerics annex be extended to include more complex functions and types. I would like to see more discrete arithmetic types. I would love to see, in order of preference: (1) Binary Galois fields. (2) Crypto-secure random numbers. (3) More modular operations. (e.g. multiplicative inverses & efficient exponentiation.) (4) Built-in multiprecision types. These have in common that highly efficient but hopelessly target dependent algorithms are known for computing these. Most of the stuff I do now is discrete, so I really have no idea what would be best for continuous types. But I guess that operations that could take advantage of SIMD extensions of some processors would be useful. Well anything that would likely speed up a Fourier Transform would be a bonus. For example like Fortran, built-in point to point multiplication of arrays would be good. On the abstraction side, the fact that arrays and functions are addressed with the same syntax is a fun thing in Ada. Perhaps this could be taken further? -- Frank ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Math Libraries (was Re: Ada2005) 2001-12-20 20:14 ` FGD @ 2001-12-20 20:34 ` Marin David Condic 2001-12-21 17:21 ` FGD 0 siblings, 1 reply; 83+ messages in thread From: Marin David Condic @ 2001-12-20 20:34 UTC (permalink / raw) I could see that objection, but it still seems that it would be nice to have something like this available for other numeric types. Personally, I'd be willing to live with the possibility that for a number of particularly small fixed or decimal types, the computations might generate Constraint_Error so long as for the ones that were big enough I got a result. Its up to the user to define types of sufficient size and precision to have something like Sqrt make sense for it. Clearly, the original package was intended to line up nicely with hardware or OS supplied libraries and I see no reason that it should change. I'm thinking along the lines of extention in other packages that might have to do their computation strictly in the Ada language. It might not even need to be under Ada.Numerics. I might not object if the underlying implementation did conversions to some floating point type and converted the result back to whatever it had to. Sure, I could do it myself, but having things like Log and Sqrt available for fixed and decimal types seems almost as fundamental as having "+" and "-". Its pretty basic to most math that is just a bit more complex than balancing my checkbook. (Maybe even there as well - you need Sqrt to compute interest, don't you? :-) You're probably right about it being considered and rejected for Ada95. Maybe its time to reconsider? Other extensions I think would be useful here would be vector and matrix math. That shows up often enough to be generally useful and there are already a number of packages available to do it. So it could be a case of standardizing on an existing library - if I dare bring that up! :-) I'd also vote for statistics - partly because I think it would get used a lot and partly because I just like statistics. (A friend once described it this way: Statistics is to Math what The National Enquirer is to Journalism. :-) Other languages provide some math capabilities, but generally don't go this far. That would make Ada even more useful in the math realm than it already is. And I don't think its a stretch too far from the beaten path to cover vectors, matricese and statistics. Those areas are used often enough that it wouldn't seem "strange" to support them. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "FGD" <presbeis@look.ca> wrote in message news:3C22468C.30901@look.ca... > > > There is a range issue here, most of these functions will map out of the > range of the original type or will have unsatisfactory precision within > the original type--such extensions are generally useless. Converting to > float and using the float result is usually the best solution. For most > of the remaining cases converting back from float to the original type > is the most efficient way to compute the desired result. For the very > few remaining cases, the programer should be able to supply efficient > algorithms. > > I think all of this was considered when designing Ada95. > ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Math Libraries (was Re: Ada2005) 2001-12-20 20:34 ` Marin David Condic @ 2001-12-21 17:21 ` FGD 2001-12-21 18:08 ` Marin David Condic 2002-01-02 14:20 ` Jacob Sparre Andersen 0 siblings, 2 replies; 83+ messages in thread From: FGD @ 2001-12-21 17:21 UTC (permalink / raw) I agree that linear algebra types such as vector and matrix would be a nice language extension. These would benefit the most from hardware extensions such as SIMD, and having them within the language would ensure that all target machines are exploited to their full potential. I would like to be able to write type Domain_Space is vector (1 .. D) of Float; type Range_Space is vector (1 .. R) of Float; type Transform is matrix (Domain_Space, Range_Space); F, G : Transform; U, V : Domain_Space; X, Y : Range_Space; S : Float; ................... X := F * U; Y := (F + G) * (U + S * V) - X; where all operators are defined within the language, all checks made at compile time. Note that the semantics become pretty complicated here for language defined objects---some might object to that. It's very unusual to have predefined mixed-type operations. I think vector and matrix should be fairly distinct from array. It would be very inconvenient if any array of floats came with predefined +, -, *, etc. I'm not too sure about stats. Basic stats can be handled with linear algebra and elementary math. The problem is that it's not clear where to stop. It's something to think about... -- Frank Marin David Condic wrote: > I could see that objection, but it still seems that it would be nice to have > something like this available for other numeric types. Personally, I'd be > willing to live with the possibility that for a number of particularly small > fixed or decimal types, the computations might generate Constraint_Error so > long as for the ones that were big enough I got a result. Its up to the user > to define types of sufficient size and precision to have something like Sqrt > make sense for it. > > Clearly, the original package was intended to line up nicely with hardware > or OS supplied libraries and I see no reason that it should change. I'm > thinking along the lines of extention in other packages that might have to > do their computation strictly in the Ada language. It might not even need to > be under Ada.Numerics. > > I might not object if the underlying implementation did conversions to some > floating point type and converted the result back to whatever it had to. > Sure, I could do it myself, but having things like Log and Sqrt available > for fixed and decimal types seems almost as fundamental as having "+" and > "-". Its pretty basic to most math that is just a bit more complex than > balancing my checkbook. (Maybe even there as well - you need Sqrt to compute > interest, don't you? :-) > > You're probably right about it being considered and rejected for Ada95. > Maybe its time to reconsider? > > Other extensions I think would be useful here would be vector and matrix > math. That shows up often enough to be generally useful and there are > already a number of packages available to do it. So it could be a case of > standardizing on an existing library - if I dare bring that up! :-) > > I'd also vote for statistics - partly because I think it would get used a > lot and partly because I just like statistics. (A friend once described it > this way: Statistics is to Math what The National Enquirer is to Journalism. > :-) > > Other languages provide some math capabilities, but generally don't go this > far. That would make Ada even more useful in the math realm than it already > is. And I don't think its a stretch too far from the beaten path to cover > vectors, matricese and statistics. Those areas are used often enough that it > wouldn't seem "strange" to support them. > > MDC > -- > Marin David Condic > Senior Software Engineer > Pace Micro Technology Americas www.pacemicro.com > Enabling the digital revolution > e-Mail: marin.condic@pacemicro.com > Web: http://www.mcondic.com/ > > > "FGD" <presbeis@look.ca> wrote in message news:3C22468C.30901@look.ca... > >> >>There is a range issue here, most of these functions will map out of the >>range of the original type or will have unsatisfactory precision within >>the original type--such extensions are generally useless. Converting to >>float and using the float result is usually the best solution. For most >>of the remaining cases converting back from float to the original type >>is the most efficient way to compute the desired result. For the very >>few remaining cases, the programer should be able to supply efficient >>algorithms. >> >>I think all of this was considered when designing Ada95. >> >> > > > ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Math Libraries (was Re: Ada2005) 2001-12-21 17:21 ` FGD @ 2001-12-21 18:08 ` Marin David Condic 2001-12-21 19:40 ` tmoran ` (3 more replies) 2002-01-02 14:20 ` Jacob Sparre Andersen 1 sibling, 4 replies; 83+ messages in thread From: Marin David Condic @ 2001-12-21 18:08 UTC (permalink / raw) "FGD" <presbeis@look.ca> wrote in message news:3C236F94.7020101@look.ca... > > I agree that linear algebra types such as vector and matrix would be a > nice language extension. These would benefit the most from hardware I don't know that it needs to be a language extension. That starts asking for something that is harder to do than simply providing a package and I don't see an enormous amount of utility to it. Most Ada programmers would probably easily comprehend and work with a package that defined "+" and so on for a vector or matrix type so I think you could get the features (albeit maybe not quite as cleanly) without forcing the compiler writers to make the language itself more complex. > extensions such as SIMD, and having them within the language would > ensure that all target machines are exploited to their full potential. > Obviously, it would be advantageous for a compiler writer to take advantage of any underlying hardware rather than rely strictly on Ada syntax to implement the type. The nice thing about implementing it as a package is that the body could be implementation dependent, but the spec could be portable. If you've got the hardware, implement it in assembler. > > I'm not too sure about stats. Basic stats can be handled with linear > algebra and elementary math. The problem is that it's not clear where to > stop. It's something to think about... > I'm thinking that some packages to get you things like mean, variance, standard deviation, etc., from arrays of various numeric types would be enough - for now. :-) (I've got some packages that do this already - it really isn't that hard to implement.) Sure, you could imagine all kinds of wonerful sophistication that one might get from a true statistical package, but why push our luck? Settle for some nice, basic statistics that let people throw some analysis into their run-of-the-mill apps rather than shoot for something that would satisfy the full-blown statisticians. It would still be ahead of most other languages I'm aware of and wouldn't require some major revision to the language syntax or semantics. Just a thought.... MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Math Libraries (was Re: Ada2005) 2001-12-21 18:08 ` Marin David Condic @ 2001-12-21 19:40 ` tmoran 2001-12-21 19:45 ` Marin David Condic 2001-12-21 20:35 ` Dan Nagle 2001-12-21 20:31 ` Eric Merritt ` (2 subsequent siblings) 3 siblings, 2 replies; 83+ messages in thread From: tmoran @ 2001-12-21 19:40 UTC (permalink / raw) A long time ago my Ada compiler vendor included a NAG (Numerical Analysis Group?) library. It had most of this stuff. Does it still exist? ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Math Libraries (was Re: Ada2005) 2001-12-21 19:40 ` tmoran @ 2001-12-21 19:45 ` Marin David Condic 2001-12-21 20:35 ` Dan Nagle 1 sibling, 0 replies; 83+ messages in thread From: Marin David Condic @ 2001-12-21 19:45 UTC (permalink / raw) That would be something interesting - if one or more vendors was already supporting a math library that did linear-a and stats. (I'm assuming you mean that this was a byproduct of some Ada interest group?) I'm in favor of glomming onto any of the things that might already be semi-standards & getting them more widely accepted. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ <tmoran@acm.org> wrote in message news:4fMU7.19924$Ah.630297@rwcrnsc52... > A long time ago my Ada compiler vendor included a NAG (Numerical > Analysis Group?) library. It had most of this stuff. Does it > still exist? ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Math Libraries (was Re: Ada2005) 2001-12-21 19:40 ` tmoran 2001-12-21 19:45 ` Marin David Condic @ 2001-12-21 20:35 ` Dan Nagle 1 sibling, 0 replies; 83+ messages in thread From: Dan Nagle @ 2001-12-21 20:35 UTC (permalink / raw) Hello, Check at www.nag.co.uk to see if they support an Ada binding. A quick check didn't show me anything about Ada, but you may be able to use the Fortran or C bindings to gain access if NAG supports a target compiler your Ada compiler supports. -- Cheers! Dan Nagle Purple Sage Computing Solutions, Inc. On Fri, 21 Dec 2001 19:40:48 GMT, tmoran@acm.org wrote: >A long time ago my Ada compiler vendor included a NAG (Numerical >Analysis Group?) library. It had most of this stuff. Does it >still exist? ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Math Libraries (was Re: Ada2005) 2001-12-21 18:08 ` Marin David Condic 2001-12-21 19:40 ` tmoran @ 2001-12-21 20:31 ` Eric Merritt 2001-12-22 16:56 ` Math Update for Ada 2005 Steven Deller 2001-12-22 21:48 ` Math Libraries (was Re: Ada2005) FGD 3 siblings, 0 replies; 83+ messages in thread From: Eric Merritt @ 2001-12-21 20:31 UTC (permalink / raw) To: comp.lang.ada --- Marin David Condic <dont.bother.mcondic.auntie.spam@[acm.org>]>, MISSING_MAILBOX_TERMINATOR@.SYNTAX-ERROR. wrote: > "FGD" <presbeis@look.ca> wrote in message > news:3C236F94.7020101@look.ca... > > > > I agree that linear algebra types such as vector > and matrix would be a > > nice language extension. These would benefit the > most from hardware > > I don't know that it needs to be a language > extension. That starts asking > for something that is harder to do than simply > providing a package and I > don't see an enormous amount of utility to it. Most > Ada programmers would > probably easily comprehend and work with a package > that defined "+" and so > on for a vector or matrix type so I think you could > get the features (albeit > maybe not quite as cleanly) without forcing the > compiler writers to make the > language itself more complex. > Why not add this to the current ACL initiative. __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com ^ permalink raw reply [flat|nested] 83+ messages in thread
* Math Update for Ada 2005 2001-12-21 18:08 ` Marin David Condic 2001-12-21 19:40 ` tmoran 2001-12-21 20:31 ` Eric Merritt @ 2001-12-22 16:56 ` Steven Deller 2001-12-23 15:13 ` Robert Dewar 2001-12-22 21:48 ` Math Libraries (was Re: Ada2005) FGD 3 siblings, 1 reply; 83+ messages in thread From: Steven Deller @ 2001-12-22 16:56 UTC (permalink / raw) To: comp.lang.ada All the email about Math libraries reminded me of one of Ada 95's shortcomings. The IEEE math definitions have included NaN and Inf semantics for quite some time. Many (if not all) native platforms and many embedded platforms can support this. I have run into C++ and C code that uses these. Ada 95 does NOT support these. Interfacing Ada with C or C++ code that uses these can be quite a pain. How could we add these semantics into Ada 2005 without breaking past code and without *forcing* platforms to support this (if they don't do so easily). My thought was to have some sort of program wide values for floating point (settable?), with appropriate attributes to query the settings. Is that reasonable? Does anyone else want these semantics available? Suppose you have a subtype with narrow constraints (less than the 'Base range). Would Inf and NaN apply? I believe it would. I'd suggest that wherever raising constraint_error (for these types) would occur, instead the values would be set directly to "Inf" or "NaN" (consistent with IEEE semantics). Basically, if 'Base includes Inf and NaN values, then any subtype would include them as well. Or more to the point, any and all floating point types either would, or would not, include the values Inf and NaN (and appropriate semantics). Addition of these values would not require any additional constraint checking beyond that which is done now. Wherever code (without NaN and Inf) would have done a constraint check: if val<low_bound then raise constraint_error if val>hi_bound then raise constraint_error code (with NaN and Inf) would now be generated as if val /= NaN and val<low_bound then val := -Inf if val /= NaN and val>hi_bound then val := +Inf I seem to recall (?) that the "two" predicates are really just one test in IEEE arithmetic, i.e. I believe there is a way to check for something being "commensurate" and then comparing values, so the resulting code should not be any more complex or costly than current code. Typical application code could then look like: do lots of computations to compute one or more values if val = Inf then do things based on value going out of range including possibly explicitly raising constraint_error end if if val = NaN then ... The state could even be settable (perhaps at execution startup). In that case, there would have to be a test for the state (to decide whether to raise constraint_error or set a value to +/-Inf) though there might be some clever load time operations that could eliminate that test. This model can simplify code in many situations. When it is EXPECTED that something may go out of range and "that is ok", then raising an exception is not necessarily the right thing to do, particularly if the computation code "consumes" some inputs. The current Ada model *forces* an application to either "consume all data before computing", wrap an exception handler around every data "consumption", or have coupling between code and one "overall" exception handler so the handler knows how much data to "skip". None of these may be as satisfactory as: loop get data compute some get more data compute some get more data compute some if NaN or Inf values then output something else output something else end if end loop Regards, Steven Deller ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Math Update for Ada 2005 2001-12-22 16:56 ` Math Update for Ada 2005 Steven Deller @ 2001-12-23 15:13 ` Robert Dewar 2001-12-23 22:43 ` Brian Rogoff 0 siblings, 1 reply; 83+ messages in thread From: Robert Dewar @ 2001-12-23 15:13 UTC (permalink / raw) "Steven Deller" <deller@smsail.com> wrote in message news:<mailman.1009040342.32000.comp.lang.ada@ada.eu.org>... > All the email about Math libraries reminded me of one of Ada 95's > shortcomings. > > The IEEE math definitions have included NaN and Inf semantics for quite > some time. Many (if not all) native platforms and many embedded > platforms can support this. I have run into C++ and C code that uses > these. Ada 95 does NOT support these. Ada 95 was carefully designed so that support can be added for infinities and Nan's without in anyway violating the RM semantics, and in fact GNAT does support the use of Inf and Nan semantics in full generality, though it does not provide all the IEEE facilities for manipulating such values. These facilities can be added with external packages. For an *extensive* discussion of this entire issue see Sam Figueroa's thesis (NYU, Robert Dewar thesis advisor). This thesis addresses the entire issue of floating-point evaluation schemes in high level languages from an IEEE point of view, and specifically proposes a package and other facilities (pragmas attributes etc) for full support of the IEEE model in Ada 95 in an upwards compatible manner. At least start from Sam's work, don't reinvent the wheel :-) ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Math Update for Ada 2005 2001-12-23 15:13 ` Robert Dewar @ 2001-12-23 22:43 ` Brian Rogoff 0 siblings, 0 replies; 83+ messages in thread From: Brian Rogoff @ 2001-12-23 22:43 UTC (permalink / raw) On 23 Dec 2001, Robert Dewar wrote: > Ada 95 was carefully designed so that support can be > added for infinities and Nan's without in anyway violating > the RM semantics, and in fact GNAT does support the use of > Inf and Nan semantics in full generality, though it does > not provide all the IEEE facilities for manipulating such > values. > > These facilities can be added with external packages. For > an *extensive* discussion of this entire issue see Sam > Figueroa's thesis (NYU, Robert Dewar thesis advisor). This > thesis addresses the entire issue of floating-point evaluation schemes > in high level languages from an IEEE > point of view, and specifically proposes a package and > other facilities (pragmas attributes etc) for full support > of the IEEE model in Ada 95 in an upwards compatible manner. > > At least start from Sam's work, don't reinvent the wheel :-) Excellent advice, thanks. I'll answer the next question for the clueless http://www.cs.nyu.edu/csweb/Research/Theses/figueroa_sam.pdf -- Brian ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Math Libraries (was Re: Ada2005) 2001-12-21 18:08 ` Marin David Condic ` (2 preceding siblings ...) 2001-12-22 16:56 ` Math Update for Ada 2005 Steven Deller @ 2001-12-22 21:48 ` FGD 3 siblings, 0 replies; 83+ messages in thread From: FGD @ 2001-12-22 21:48 UTC (permalink / raw) I'm not completely for extending Ada to include new math types. As I stressed earlier such extensions would generally be useless for most people. The only possible exception I can see is linear algebra... Marin David Condic wrote: > "FGD" <presbeis@look.ca> wrote in message news:3C236F94.7020101@look.ca... > >>I agree that linear algebra types such as vector and matrix would be a >>nice language extension. These would benefit the most from hardware >> > > I don't know that it needs to be a language extension. That starts asking > for something that is harder to do than simply providing a package and I > don't see an enormous amount of utility to it. Most Ada programmers would > probably easily comprehend and work with a package that defined "+" and so > on for a vector or matrix type so I think you could get the features (albeit > maybe not quite as cleanly) without forcing the compiler writers to make the > language itself more complex. The reason why I mentionned it as a language extension is that the "matrix type" is simply not efficient when represented as an array of coefficients. Having a language defined matrix type acting on vector types leaved the compiler writers free to use whatever internal representation they like. >>extensions such as SIMD, and having them within the language would >>ensure that all target machines are exploited to their full potential. >> >> > Obviously, it would be advantageous for a compiler writer to take advantage > of any underlying hardware rather than rely strictly on Ada syntax to > implement the type. The nice thing about implementing it as a package is > that the body could be implementation dependent, but the spec could be > portable. If you've got the hardware, implement it in assembler. Of course, that's what we currently do---in Ada and all other general-purpose languages. But one of the main advantages of Ada is low maintenace cost. I, for one, write and maintain a lot of such packages but almost all of my maintenance work goes into code that looks like: procedure Whatever ... begin case Machine is when Alpha_EV4 => Asm(.... when X86_Pentium_3 => Asm(.... when others => .... end case; end Whatever; For example, when Intel released the Pentum 4, I spent weeks rewrite and test asm code for relatively basic little things. I still have months to go writing and testing new code for the Itanium chip... and then the AMD-64... Sigh! :-( For such code, Ada doesn't present any more advantages than any other language. Of course, that only leaves the burden of asm maintenance to compiler writers. Still having a few non-elementary types such as matrix and vector would make my life a lot simpler sometimes. >>I'm not too sure about stats. Basic stats can be handled with linear >>algebra and elementary math. The problem is that it's not clear where to >>stop. It's something to think about... >> >> > I'm thinking that some packages to get you things like mean, variance, > standard deviation, etc., from arrays of various numeric types would be > enough - for now. :-) (I've got some packages that do this already - it > really isn't that hard to implement.) Sure, you could imagine all kinds of > wonerful sophistication that one might get from a true statistical package, > but why push our luck? Settle for some nice, basic statistics that let > people throw some analysis into their run-of-the-mill apps rather than shoot > for something that would satisfy the full-blown statisticians. It would > still be ahead of most other languages I'm aware of and wouldn't require > some major revision to the language syntax or semantics. There are already lots of stuff out there to satisfy "full-blown" statisticians and mathematicians. Ada has no business there. We should focus on stuff that is useful to a great deal of people. As far as I can tell, linear algebra with all of its applications is the only branch of math which is useful to a great deal of people. BTW mean, variance and standard deviation are all linear algebra except maybe for a few square roots here and there. -- Frank ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Math Libraries (was Re: Ada2005) 2001-12-21 17:21 ` FGD 2001-12-21 18:08 ` Marin David Condic @ 2002-01-02 14:20 ` Jacob Sparre Andersen 1 sibling, 0 replies; 83+ messages in thread From: Jacob Sparre Andersen @ 2002-01-02 14:20 UTC (permalink / raw) FGD wrote: > I agree that linear algebra types such as vector and matrix would be a > nice language extension. I would prefer that they were added as some extra packages, and not as new basic types. There is no point in changing the language itself, if the problem can be solved within the current framework. It is trivial to implement a vector type yourself (see http://jacob.sparre.dk/Ada/matematik/ for an example). Matrices are a bit harder, if we want full compile time checking of the dimensions of the matrices. Jacob -- I �vrigt mener jeg at det er uhensigtsm�ssigt at skrive "pipes" om kanaler i en begynderbog om Unix. ^ permalink raw reply [flat|nested] 83+ messages in thread
* RE: Math Libraries (was Re: Ada2005) 2001-12-20 16:34 ` Math Libraries (was Re: Ada2005) Marin David Condic 2001-12-20 20:14 ` FGD @ 2001-12-20 23:20 ` Robert C. Leif, Ph.D. 2001-12-21 14:49 ` Marin David Condic 1 sibling, 1 reply; 83+ messages in thread From: Robert C. Leif, Ph.D. @ 2001-12-20 23:20 UTC (permalink / raw) To: comp.lang.ada From: Bob Leif To: Marin Condic et al., I agree; however, I believe that a decimal floating type should be created or a work-around be provided to circumvent the static restrictions on type decimal. I still wish to be able to specify the exponent at run-time. PC performance has long since passed the point of needing to match the numeric format to the machine instead of the human. For most commercial uses, decimal numbers are a much better choice than binary numbers. I might note than even in the computer aided design of mechanical systems, decimal would be a better choice. I see errors in VISIO where a specified one or two digit number, which ends in three zeros, becomes filled with numeric characters. These numbers are sufficiently close to the value that they do not materially change it. However, the provide absolutely bizarre dimensions on a drawing and are a distraction. -----Original Message----- From: comp.lang.ada-admin@ada.eu.org [mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Marin David Condic Sent: Thursday, December 20, 2001 8:35 AM To: comp.lang.ada@ada.eu.org Subject: Math Libraries (was Re: Ada2005) We have in Ada a useful package: Ada.Numerics.Generic_Elementary_Functions that works fine for floating point types. Is there any reason not to include in Ada200x similar packages for generic fixed and decimal types? It seems we ought to be able to compute logarithms, square roots, etc. for numeric types other than floating point types, eh? Would there be any reason not to expand the math functions beyond what is already there? Math is pretty cheap to implement when compared to some of the other suggested extensions to the language and it would definitely be attractive to a given audience that might currently still be relying on Fortran. (See also the discussion elsewhere about standard libraries...) What math functions (or math branches) would be most desirable to add to the language by way of some packages under Ada.Numerics? MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Math Libraries (was Re: Ada2005) 2001-12-20 23:20 ` Robert C. Leif, Ph.D. @ 2001-12-21 14:49 ` Marin David Condic 0 siblings, 0 replies; 83+ messages in thread From: Marin David Condic @ 2001-12-21 14:49 UTC (permalink / raw) You are suggesting some version of specifying a "digits" clause but no "delta"? Then presuming the underlying implementation is some version of packed-decimal, performing effectively floating point math with some arbitrary number of digits? That I might put into the "Nice To Have" category, but I'm not sure the language would need a new data type. There are packages that define big number arithmetic & perhaps using some version of that would be a good place to start to see how useful it might be. Creating a new numeric type could be useful from a language standpoint since all the presumptions could be there about math operations, etc. (A private type with math ops defined just doesn't quite cut it - consider generics as an example) but I'd want some evidence that there is some significant user base that needs it before making it a language extension... MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Robert C. Leif, Ph.D." <rleif@rleif.com> wrote in message news:mailman.1008921920.25553.comp.lang.ada@ada.eu.org... > From: Bob Leif > To: Marin Condic et al., > I agree; however, I believe that a decimal floating type should be created > or a work-around be provided to circumvent the static restrictions on type > decimal. I still wish to be able to specify the exponent at run-time. > PC performance has long since passed the point of needing to match the > numeric format to the machine instead of the human. For most commercial > uses, decimal numbers are a much better choice than binary numbers. > ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Ada2005 @ 2001-12-12 14:05 Peter Hermann 0 siblings, 0 replies; 83+ 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] 83+ messages in thread
* 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; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ messages in thread
* Re: Ada2005 2002-12-18 14:48 ` Ada2005 Ted Dennison @ 2002-12-19 9:01 ` Anders Wirzenius 0 siblings, 0 replies; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ 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; 83+ 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] 83+ messages in thread
end of thread, other threads:[~2005-03-24 15:32 UTC | newest] Thread overview: 83+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 2001-12-20 16:34 ` Math Libraries (was Re: Ada2005) Marin David Condic 2001-12-20 20:14 ` FGD 2001-12-20 20:34 ` Marin David Condic 2001-12-21 17:21 ` FGD 2001-12-21 18:08 ` Marin David Condic 2001-12-21 19:40 ` tmoran 2001-12-21 19:45 ` Marin David Condic 2001-12-21 20:35 ` Dan Nagle 2001-12-21 20:31 ` Eric Merritt 2001-12-22 16:56 ` Math Update for Ada 2005 Steven Deller 2001-12-23 15:13 ` Robert Dewar 2001-12-23 22:43 ` Brian Rogoff 2001-12-22 21:48 ` Math Libraries (was Re: Ada2005) FGD 2002-01-02 14:20 ` Jacob Sparre Andersen 2001-12-20 23:20 ` Robert C. Leif, Ph.D. 2001-12-21 14:49 ` Marin David Condic -- strict thread matches above, loose matches on Subject: below -- 2001-12-12 14:05 Ada2005 Peter Hermann 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 2005-03-24 14:36 Ada2005 Szymon Guz 2005-03-24 15:30 ` Ada2005 Xaelis 2005-03-24 15:32 ` Ada2005 Larry Kilgallen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox