* Idea for Ada 200x: Arguments that are procedures @ 1998-07-03 0:00 Van Snyder 1998-07-02 0:00 ` Robert Dewar ` (3 more replies) 0 siblings, 4 replies; 14+ messages in thread From: Van Snyder @ 1998-07-03 0:00 UTC (permalink / raw) Procedures that are arguments are restricted in Ada because of the possibility of copying the pointer to somewhere that has a longer lifetime than the up-level environment of the procedure. If an additional attribute were added to formal arguments to indicate that taking a copy of a procedure pointer is prohibited, restrictions on procedures that could be arguments could be reduced. Since "limited" already puts restrictions on assignment, how about using that word for the purpose of declaring a formal argument for which it's prohibited to take a copy. It could only be used to access a procedure, or passed as an actual argument to a formal argument that also had the "limited" attribute. This would let me have, for example, a library package for quadrature or minimization or differential equations or ... that exports a type for a procedure pointer argument, and use a procedure that's internal to my deep-in-the-guts-of-the-system procedure as the actual argument. I can't do this now, because the type might outlive the procedure, and therefore a pointer to the procedure might outlive its up-level. -- What fraction of Americans believe | Van Snyder Wrestling is real and NASA is fake? | vsnyder@math.jpl.nasa.gov ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Idea for Ada 200x: Arguments that are procedures 1998-07-03 0:00 Idea for Ada 200x: Arguments that are procedures Van Snyder @ 1998-07-02 0:00 ` Robert Dewar 1998-07-02 0:00 ` Brian Rogoff ` (2 subsequent siblings) 3 siblings, 0 replies; 14+ messages in thread From: Robert Dewar @ 1998-07-02 0:00 UTC (permalink / raw) Van Snyder says <<If an additional attribute were added to formal arguments to indicate that taking a copy of a procedure pointer is prohibited, restrictions on procedures that could be arguments could be reduced. Since "limited" already puts restrictions on assignment, how about using that word for the purpose of declaring a formal argument for which it's prohibited to take a copy. It could only be used to access a procedure, or passed as an actual argument to a formal argument that also had the "limited" attribute. This would let me have, for example, a library package for quadrature or minimization or differential equations or ... that exports a type for a procedure pointer argument, and use a procedure that's internal to my deep-in-the-guts-of-the-system procedure as the actual argument. I can't do this now, because the type might outlive the procedure, and therefore a pointer to the procedure might outlive its up-level. >> You are assuming that the restrictions in Ada 95 are because of possible scoping and dangling reference problems. This is not the case, the limitations are there to allow the use of displays in the implementation without a lot of trouble. Alsys in particular argued very strongly that if the language design made it hard for them to maintain the use of displays, that it would be an unacceptable burden. This is actually one of the very few times that the language got restricted very specifically because of a very specific implementation approach. It is a bit ironic that in fact the old Alsys technology died anyway (to be replaced by the Intermetrics front end). I am not sure what other Ada 95 compilers actually do. GNAT uses a static chain, and it is trivial from an implementation point of view to eliminate the restrictions. Indeed the 'Unrestricted_Access attribute in GNAT allows complete freedom in the use of procedure pointers, but of course it is not protected against dangling pointers. It is of course possible to design a safe feature along the lines that Van Snyder suggests, and once again we are in the reinventing the wheel mode. I would *strongly* suggest that before you get into the lets-add-this-feature to Ada, you look at the earlier mapping documents, where many of the obvious ideas, including this one, have been explored already. Robert Dewar ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Idea for Ada 200x: Arguments that are procedures 1998-07-03 0:00 Idea for Ada 200x: Arguments that are procedures Van Snyder 1998-07-02 0:00 ` Robert Dewar @ 1998-07-02 0:00 ` Brian Rogoff 1998-07-03 0:00 ` Charles Hixson 1998-07-03 0:00 ` Steve Whalen 3 siblings, 0 replies; 14+ messages in thread From: Brian Rogoff @ 1998-07-02 0:00 UTC (permalink / raw) Hmmm, where have I heard this before! Yes Van, this one is up on my list of "most wanted for Ada 0X" too. The desire for this construct was felt during the Ada 9X design too, see http://sw-eng.falls-church.va.us/AdaIC/standards/95lsn/LSN1083.GeneralAccess The reasons why it isn't in Ada 95 are well known. Hopefullly the same excuse won't be used again, and implementors of display based Ada compilation systems will be ready. Then Ada will be "almost functional" :-) -- Brian On 3 Jul 1998, Van Snyder wrote: > Procedures that are arguments are restricted in Ada because of the > possibility of copying the pointer to somewhere that has a longer > lifetime than the up-level environment of the procedure. > > If an additional attribute were added to formal arguments to indicate > that taking a copy of a procedure pointer is prohibited, restrictions > on procedures that could be arguments could be reduced. > > Since "limited" already puts restrictions on assignment, how about > using that word for the purpose of declaring a formal argument for > which it's prohibited to take a copy. It could only be used to > access a procedure, or passed as an actual argument to a formal > argument that also had the "limited" attribute. > > This would let me have, for example, a library package for quadrature > or minimization or differential equations or ... that exports a type > for a procedure pointer argument, and use a procedure that's internal > to my deep-in-the-guts-of-the-system procedure as the actual argument. > I can't do this now, because the type might outlive the procedure, and > therefore a pointer to the procedure might outlive its up-level. > > -- > What fraction of Americans believe | Van Snyder > Wrestling is real and NASA is fake? | vsnyder@math.jpl.nasa.gov > > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Idea for Ada 200x: Arguments that are procedures 1998-07-03 0:00 Idea for Ada 200x: Arguments that are procedures Van Snyder 1998-07-02 0:00 ` Robert Dewar 1998-07-02 0:00 ` Brian Rogoff @ 1998-07-03 0:00 ` Charles Hixson 1998-07-04 0:00 ` Larry Kilgallen 1998-07-06 0:00 ` Dr Richard A. O'Keefe 1998-07-03 0:00 ` Steve Whalen 3 siblings, 2 replies; 14+ messages in thread From: Charles Hixson @ 1998-07-03 0:00 UTC (permalink / raw) Van Snyder wrote: > > Procedures that are arguments are restricted in Ada because of the > possibility of copying the pointer to somewhere that has a longer > lifetime than the up-level environment of the procedure. > /* snip */ > to my deep-in-the-guts-of-the-system procedure as the actual argument. > I can't do this now, because the type might outlive the procedure, and > therefore a pointer to the procedure might outlive its up-level. > > -- > What fraction of Americans believe | Van Snyder > Wrestling is real and NASA is fake? | vsnyder@math.jpl.nasa.gov I find the lack of a decent garbage collector to be a MUCH more troublesome problem. This is especially so as data allocated in library units is not automatically freed during the program execution. On the other hand, it's VERY difficult to check that there are no dangling references, so Unchecked_DeAllocation always feels very dangerous. On the third hand, Java's "lets garbage collect EVERYTHING" seems excessive, and has GOT to be a part of what slows Java down. This seems to be the kind of thing with so many possibilities and internal dependancies that it is best dealt with by the compiler writer. And the memory leaks in various commercial applications demonstrates very clearly how important an issue it is (i.e., enough so that I prefer Java's approach to C++'s). A second, and distinctly less important proposal, would be some way of inserting common ancestors into a hierarchy, even it they needed to be inserted as fully abstract classes. Reorganizing the grouping of their concepts (maps to hierarchies) is one of the important things that people do, so I feel that the language should support it. People don't usually form a category until after they have collected several examples that could fit into it. And since programmers are people I expect that others also keep having to reorganize their classes as time passes. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Idea for Ada 200x: Arguments that are procedures 1998-07-03 0:00 ` Charles Hixson @ 1998-07-04 0:00 ` Larry Kilgallen 1998-07-06 0:00 ` Dr Richard A. O'Keefe 1 sibling, 0 replies; 14+ messages in thread From: Larry Kilgallen @ 1998-07-04 0:00 UTC (permalink / raw) In article <359D41CE.D3976FA6@earthlink.net>, Charles Hixson <charleshixsn@earthlink.net> writes: > Van Snyder wrote: >> >> Procedures that are arguments are restricted in Ada because of the >> possibility of copying the pointer to somewhere that has a longer >> lifetime than the up-level environment of the procedure. >> > /* snip */ >> to my deep-in-the-guts-of-the-system procedure as the actual argument. >> I can't do this now, because the type might outlive the procedure, and >> therefore a pointer to the procedure might outlive its up-level. > I find the lack of a decent garbage collector to be a MUCH more > troublesome problem. So speak to your compiler vendor about garbage collection. That does not seem to be a standards issue, and until there are more Ada garbage collection implementations in use, it would seem presumptuous to attempt to decide what constituted a "decent" one. Larry Kilgallen ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Idea for Ada 200x: Arguments that are procedures 1998-07-03 0:00 ` Charles Hixson 1998-07-04 0:00 ` Larry Kilgallen @ 1998-07-06 0:00 ` Dr Richard A. O'Keefe 1 sibling, 0 replies; 14+ messages in thread From: Dr Richard A. O'Keefe @ 1998-07-06 0:00 UTC (permalink / raw) Charles Hixson wrote: > references, so Unchecked_DeAllocation always feels very dangerous. On > the third hand, Java's "lets garbage collect EVERYTHING" seems > excessive, and has GOT to be a part of what slows Java down. Yes and no. Java's object creation times (using Sun's JDK on a SPARC) are _huge_ compared with other operations, and _way_ bigger than object creation in for example Smalltalk, which also has quasi-parallel OOP. One of the Erlang people pointed out to me that existing Java systems have a single shared heap instead of a per-thread heap, so that object creation has to involve locking, but that can't be the whole story. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Idea for Ada 200x: Arguments that are procedures 1998-07-03 0:00 Idea for Ada 200x: Arguments that are procedures Van Snyder ` (2 preceding siblings ...) 1998-07-03 0:00 ` Charles Hixson @ 1998-07-03 0:00 ` Steve Whalen 1998-07-03 0:00 ` Brian Rogoff 1998-07-03 0:00 ` Robert Dewar 3 siblings, 2 replies; 14+ messages in thread From: Steve Whalen @ 1998-07-03 0:00 UTC (permalink / raw) Van, I'd vote for "fixing" this deficiency in the Ada200x version of the language. The way you suggested using "limited" for procedures as parameters seems like a reasonable syntax to me. Compared to GNAT's Unrestricted_Access attribute I would MUCH prefer your approach because (to me) such attributes are way too powerful (and implementation dependant). This is about the only language issue I've seen raised on comp.lang.ada that actually causes me problems in *my* "real world". It seems silly to keep requiring workarounds for a deceased implementation. I hope you'll follow up on this with whomever one follows up with in order to get this on the official list of things to add to Ada200x. I couldn't find the old discussions of this particular issue in the Mapping / Revision Team stuff, or the Language Study Notes. However, if there was no better reason for keeping this feature out of the language than that implementations using displays would have problems, I think this "fix" absolutely should make it into Ada200x. Steve -- {===--------------------------------------------------------------===} Steve Whalen swhalen@netcom.com {===--------------------------------------------------------------===} ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Idea for Ada 200x: Arguments that are procedures 1998-07-03 0:00 ` Steve Whalen @ 1998-07-03 0:00 ` Brian Rogoff 1998-07-03 0:00 ` Steve Whalen 1998-07-03 0:00 ` Robert Dewar 1 sibling, 1 reply; 14+ messages in thread From: Brian Rogoff @ 1998-07-03 0:00 UTC (permalink / raw) On Fri, 3 Jul 1998, Steve Whalen wrote: > Van, > > I'd vote for "fixing" this deficiency in the Ada200x version of the > language. The way you suggested using "limited" for procedures as > parameters seems like a reasonable syntax to me. > > Compared to GNAT's Unrestricted_Access attribute I would MUCH prefer > your approach because (to me) such attributes are way too powerful > (and implementation dependant). I think you would agree with Robert Duff, who floated the limited access type for procedure parameters a while ago, in http://sw-eng.falls-church.va.us/AdaIC/standards/95lsn/LSN1083.GeneralAccess as I pointed out in my reply to Van Snyder. If you really want to go digging, I've appended a post from Norman Cohen on this topic; you can use the thread title to trace the entire thread under DejaNews. > This is about the only language issue I've seen raised on > comp.lang.ada that actually causes me problems in *my* "real world". > It seems silly to keep requiring workarounds for a deceased > implementation. I think more than one implementation uses displays, and there is also the issue of problems caused in implementations with shared generics. FWIW, I started out with your view (omission of downward closures was an egregious mistake) and ended up agreeing that it was the only right thing to do for Ada *95*. However, I have wanted this in code I write and I think the workarounds are really clumsy and impair readability. I'd rather that generics were never shared, if the interaction of the two features is problematic! I guess the thing to do is to ask your Ada compiler vendor to provide this feature in some form, so that even if we have N variants for N vendors at least the economic argument will be weakened. -- Brian From ncohen@watson.ibm.com Thu Jul 11 10:13:24 1996 From: ncohen@watson.ibm.com (Norman H. Cohen) Newsgroups: comp.lang.ada Subject: Re: Q: access to subprogram Date: 11 Jul 1996 00:49:51 GMT Organization: IBM T.J. Watson Research Center Distribution: world Reply-To: ncohen@watson.ibm.com NNTP-Posting-Host: rios8.watson.ibm.com In article <ROGOFF.96Jul8155205@sccm.Stanford.EDU>, rogoff@sccm.Stanford.EDU (Brian Rogoff) writes: |> ncohen@watson.ibm.com (Norman H. Cohen) writes: ... |> Bill Taylor had made what I considered an |> irrefutable case for downward closures, showing how much easier it would |> be to write iterators if downward closures were allowed. It came down to |> a conflict between the interests of Ada programmers and the interests of |> a minority of Ada implementors, and in this case the interests of the few |> implementors using displays prevailed.) |> |> Could you summarize or provide a reference to Bill Taylor's work? Does it |> answer the objection that downward closures impose an inefficiency on programs |> that don't use them? Bill Taylor's contribution was part of an ongoing discussion in the form of comments sent to the Mapping/Revision Team during the design of Ada 9X. All of these comments from June 1992 on are publicly available in the following directory: ftp://sw-eng.falls-church.va.us/public/AdaIC/standards/95com/mrtcomments/ All the comments through April 1994 are in files with names of the form YYMMmrt.zip, where YY and MM are the year and month the comment was received. (Thus all comments from May 1993 are in 9305mrt.zip.) Starting with May 1994, there are individual daily files, such as 94.0501 for all comments received on May 1, 1994. The discussion on downward closures and their impact on display implementations included the following comments: Date Comment ID Author My summary April 29, 1993 93.2622.b Bill Taylor The initial message about iterators mentioned above. May 1, 1993 93-2628.b Robert Duff Says he likes the feature, but Robert Dewar has frightened WG9 members about the cost, and the MRT won't add downward closures until someone convinces WG9 otherwise. Claims the size of a display is not known at compile time. May 3, 1993 93-2634.a Norman Cohen Reply to Duff, asserting that the size of a display IS known at compile time. Foreshadows an identical exchange that will take place on comp.lang.ada in July 1996. :-) May 3, 1993 93-2635.a Robert Duff Reply to Cohen. Size of a display is not known at the site of a call through a pointer. Says he hates arguing against a feature he likes. May 3, 1993 93-2637.a Randy Brukardt Reports that Janus/Ada uses (RR Software) displays. Proposes a workaround involving unchecked conversion. May 3, 1993 93-2638.a Robert Duff Reply to Brukardt, asking him to explain workaround. May 4, 1993 93-2644.a Antoine Bertier Reports that Alsys uses (Alsys) displays for most of its compilers. May 4, 1993 93-2645.a Ted Baker Calls displays an "anachronism", except on register-poor machines. May 4, 1993 93-2646.a Randy Brukardt Reply to Duff, explaining his workaround and conceding that it is not portable to compilers that do NOT use displays. May 5, 1993 93-2647.a Brian Dobbing Also reports that Alsys (Alsys) uses displays, states that Alsys cannot afford any more language changes with such great impact on their compilers, and states that neither the display approach nor the static link approach is always the right choice. May 5, 1993 93-2651.a Bill Taylor Points out that Brukhardt's proposed workaround does not work when the pointed- to procedures reference data in surrounding scopes, as they do in his iterators example. May 5, 1993 93-2655.a Robert Dewar Reply to Baker, defending displays and asserting that they can be quite efficient. May 5, 1993 93-2656.a Robert Eachus Experiments (with a compiler that was altered to send Eachus e-mail every time code was generated for a call on a nested subprogram!) show that calls on nested procedure are rare, so the expense of supporting this feature is not justified. May 6, 1993 93-2661.a Ted Baker Reply to Dewar, claiming that downward closures were important for the kind of applications that justified ANY inclusion of 'Access for nested subprograms in Ada 9X, and worth the cost; but admitting that Brian Dobbing's economic argument might be the deciding consideration. May 11, 1993 93-2676.a Randy Brukardt Reply to Baker. May 11, 1993 93-2676.b Randy Brukardt States that downward closures impose a distributed overhead on all uses of generics when generics are implemented by shared code for all instances, as in Janus/Ada. January 14, 1994 94-3669.a Bjorn Kallberg An eloquent case for the importance of downward closures, pointing out that their omission would create the only case in which Ada is not a functional superset of Pascal. February 15, 1994 LSN 1083 Robert Duff A dispassionate analysis of all sides of the issue, explaining why the MRT decided not to include downward closures in Ada 9X. March 4, 1994 94-3985.a David Tombs An empassioned plea to reconsider this decision. -- Norman H. Cohen ncohen@watson.ibm.com ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Idea for Ada 200x: Arguments that are procedures 1998-07-03 0:00 ` Brian Rogoff @ 1998-07-03 0:00 ` Steve Whalen 1998-07-04 0:00 ` Larry Kilgallen 1998-07-07 0:00 ` Robert I. Eachus 0 siblings, 2 replies; 14+ messages in thread From: Steve Whalen @ 1998-07-03 0:00 UTC (permalink / raw) Brian Rogoff (bpr@shell5.ba.best.com) wrote: : I think you would agree with Robert Duff, who floated the limited access : type for procedure parameters a while ago, in : http://sw-eng.falls-church.va.us/AdaIC/standards/95lsn/LSN1083.GeneralAccess : as I pointed out in my reply to Van Snyder. If you really want to go : digging, I've appended a post from Norman Cohen on this topic; you can use : the thread title to trace the entire thread under DejaNews. Thanks for the additional background. I hadn't read the LSN1083 note you referenced at the time I posted. Interesting history of this "feature". Also interesting is the thread you attached, especially the note that this is the only thing that keeps Ada95 from being a proper superset of Pascal! I guess that's one reason that Ada95's lack of downward closures feels so "wrong" to me. : I think more than one implementation uses displays, and there is also the : issue of problems caused in implementations with shared generics. : FWIW, I started out with your view (omission of downward closures was an : egregious mistake) and ended up agreeing that it was the only right thing : to do for Ada *95*. However, I have wanted this in code I write and I : think the workarounds are really clumsy and impair readability. I'd rather : that generics were never shared, if the interaction of the two features : is problematic! I agree completely. Either dump shared generics (because *I* don't often/ever? need them <g>) or add another piece of programmer control syntax to "limited" (maybe "limited controlled?") That way the programmer can "promise" the compiler that the procedure pointer REALLY won't be abused/confused and permit downward closure of procedure pointers. The code that is needed to work around this "feature" is just TOO UGLY! It seriously detracts from Ada95's "elegance" and a main reason for Ada's existance (if I wanted unreadable, difficult to maintain code, I use C++ <g>). Steve -- {===--------------------------------------------------------------===} Steve Whalen swhalen@netcom.com {===--------------------------------------------------------------===} ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Idea for Ada 200x: Arguments that are procedures 1998-07-03 0:00 ` Steve Whalen @ 1998-07-04 0:00 ` Larry Kilgallen 1998-07-07 0:00 ` Robert I. Eachus 1 sibling, 0 replies; 14+ messages in thread From: Larry Kilgallen @ 1998-07-04 0:00 UTC (permalink / raw) In article <swhalenEvJBCC.6Er@netcom.com>, swhalen@netcom.com (Steve Whalen) writes: > I agree completely. Either dump shared generics (because *I* don't > often/ever? need them <g>) or add another piece of programmer control > syntax to "limited" (maybe "limited controlled?") That way the programmer > can "promise" the compiler that the procedure pointer REALLY won't be > abused/confused and permit downward closure of procedure pointers. I have not been following this, but I look to Ada for an environment in which the programmer can "assert" but the compiler will verify. I believe features where the programmer tells the compiler "trust me" should have ugly names from the UNCHECKED_* series. Larry Kilgallen ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Idea for Ada 200x: Arguments that are procedures 1998-07-03 0:00 ` Steve Whalen 1998-07-04 0:00 ` Larry Kilgallen @ 1998-07-07 0:00 ` Robert I. Eachus 1998-07-07 0:00 ` Brian Rogoff 1 sibling, 1 reply; 14+ messages in thread From: Robert I. Eachus @ 1998-07-07 0:00 UTC (permalink / raw) In article <swhalenEvJBCC.6Er@netcom.com> swhalen@netcom.com (Steve Whalen) writes: > Also interesting is the thread you attached, especially the note that > this is the only thing that keeps Ada95 from being a proper superset > of Pascal! I guess that's one reason that Ada95's lack of downward > closures feels so "wrong" to me. Ada 83 and Ada 95 both support downward closures through use of generics. A few years ago I wrote some test programs not only to verify that the language rules permitted it, but that the implementations that used displays and/or shared generics got it right. At that time I talked to the implementors, in particular R&R about how they implemented the feature, and found that, with a generic instantiation, there is enough of a flag that something unusual is happening that they didn't have to save and store contexts on every procedure call, just when a generic is instantiated in an inner scope, and the instantiation has a subprogram parameter, and that parameter is from a nested scope. Since the feature is "in there" for when it is needed, I saw no reason to continue the fight for a simpler syntax. (Jean Pierre Rosen was the first AFAIK to point out in an Ada 9X context that generics could be used to implement downward closures, at the meeting in Switzerland. But there were Ada 83 validation tests that required that it work there, so all compilers I tested implemented it correctly.) -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Idea for Ada 200x: Arguments that are procedures 1998-07-07 0:00 ` Robert I. Eachus @ 1998-07-07 0:00 ` Brian Rogoff 0 siblings, 0 replies; 14+ messages in thread From: Brian Rogoff @ 1998-07-07 0:00 UTC (permalink / raw) On 7 Jul 1998, Robert I. Eachus wrote: > Ada 83 and Ada 95 both support downward closures through use of > generics. Don't you agree that the expression of programs which naturally use downward closures is clumsy with generics? I also question the performance impact of this "workaround". Richard O'Keefe had a very nice post last time this came up in which he benchmarked a simple numerical integration routine in Ada, Pascal, Scheme, C, and Fortran, with the Ada using generics and the Scheme (amongst others) using downward closures. The Scheme compiler was able to do some impressive optimizations and ended up performing much better; more importantly, the Scheme code was much more readable IMO than the Ada. > Since the feature is "in there" for when it > is needed, I saw no reason to continue the fight for a simpler syntax. In the context of the 9X project, this was wise. Better to have a good standard today, than a better one at some undetermined future date. But this is definitely one of those things I hope gets fixed in a future language revision. -- Brian ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Idea for Ada 200x: Arguments that are procedures 1998-07-03 0:00 ` Steve Whalen 1998-07-03 0:00 ` Brian Rogoff @ 1998-07-03 0:00 ` Robert Dewar 1998-07-03 0:00 ` Brian Rogoff 1 sibling, 1 reply; 14+ messages in thread From: Robert Dewar @ 1998-07-03 0:00 UTC (permalink / raw) Steve says <<I couldn't find the old discussions of this particular issue in the Mapping / Revision Team stuff, or the Language Study Notes. However, if there was no better reason for keeping this feature out of the language than that implementations using displays would have problems, I think this "fix" absolutely should make it into Ada200x. >> There clearly will not be an anaologous development effort for Ada 200x (compared to Ada 9X). FOr one thing the multi-million dollar funding ncessary for such an approach is not there, and second, I don't think anyone thinks it is appropriate at this stage. Instead we can expect to see implementations introduce extensions that are genuinely useful for Ada users on a gradual basis, and if and when it is time for a new standard, it is more likely to be a ratification and refinement of such existing extensions. For example, the Size attribute, *particularly* in Ada 95, where the situation has got worse due to some (in my opinion) injudicious choices to be incompatible with most existing Ada 83 implementations, obviously needs work. The Object_Size and Value_Size attributes in GNAT are essentially a proprosal in the direction of fixing this. Perhaps this is not the best solution, but experimentation of this type is clearly the right way to go in terms of implementing new features. Of course this will tend to be driven by large serious users of Ada, but that is as it should be. There are as in any language design a large diverse collection of ideas from language enthusiasts (for example, there are some who would go FAR beyond the limited access proposal, and insist on full closures), but real users doing real applications are always a somewhat more credible source of input on what the real problems are! ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Idea for Ada 200x: Arguments that are procedures 1998-07-03 0:00 ` Robert Dewar @ 1998-07-03 0:00 ` Brian Rogoff 0 siblings, 0 replies; 14+ messages in thread From: Brian Rogoff @ 1998-07-03 0:00 UTC (permalink / raw) On 3 Jul 1998, Robert Dewar wrote: > There clearly will not be an anaologous development effort for Ada 200x > (compared to Ada 9X). FOr one thing the multi-million dollar funding > ncessary for such an approach is not there, and second, I don't think > anyone thinks it is appropriate at this stage. > > Instead we can expect to see implementations introduce extensions that > are genuinely useful for Ada users on a gradual basis, and if and when it > is time for a new standard, it is more likely to be a ratification and > refinement of such existing extensions. This is sensible. > Of course this will tend to be driven by large serious users of Ada, but > that is as it should be. There are as in any language design a large > diverse collection of ideas from language enthusiasts (for example, there > are some who would go FAR beyond the limited access proposal, and insist > on full closures), but real users doing real applications are always a > somewhat more credible source of input on what the real problems are! Hopefully small and medium users won't be ignored. In any case, the idea of integrating "full" closures into an Ada targetted for the JVM is not entirely absurd, since you have GC there anyways, much like you added Unrestricted_Access since gcc uses static links anyways. -- Brian ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~1998-07-07 0:00 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1998-07-03 0:00 Idea for Ada 200x: Arguments that are procedures Van Snyder 1998-07-02 0:00 ` Robert Dewar 1998-07-02 0:00 ` Brian Rogoff 1998-07-03 0:00 ` Charles Hixson 1998-07-04 0:00 ` Larry Kilgallen 1998-07-06 0:00 ` Dr Richard A. O'Keefe 1998-07-03 0:00 ` Steve Whalen 1998-07-03 0:00 ` Brian Rogoff 1998-07-03 0:00 ` Steve Whalen 1998-07-04 0:00 ` Larry Kilgallen 1998-07-07 0:00 ` Robert I. Eachus 1998-07-07 0:00 ` Brian Rogoff 1998-07-03 0:00 ` Robert Dewar 1998-07-03 0:00 ` Brian Rogoff
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox