CVS difference for ais/ai-00250.txt

Differences between 1.3 and version 1.4
Log of other versions for file ais/ai-00250.txt

--- ais/ai-00250.txt	2000/12/14 00:10:32	1.3
+++ ais/ai-00250.txt	2000/12/22 00:23:08	1.4
@@ -3337,3 +3337,252 @@
 second.
 
 ****************************************************************
+
+From: Stephen Michell
+Sent: Wednesday, December 13, 2000 3:32 PM
+
+Thomas presented a fairly good example of how it would have helped him at the
+IRTAW in Spain in September. Maybe he can present it to this forum.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, December 13, 2000 4:11 PM
+
+More significantly, is to find at least one vendor who is willing to
+champion this extension. Right now, speaking for Ada Core Technologies,
+we do not see a customer demand for this feature -- of course that can
+always change in the future.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Thursday, December 14, 2000 1:55 AM
+To: ARG@ACM.ORG
+Subject: Re: Ai on extensible protected types
+
+> <<Thomas presented a fairly good example of how it would have helped him
+> at the IRTAW in Spain in September. Maybe he can present it to this forum.
+> >>
+
+It is not hard to make a _technical_ case for this AI.  From a language
+lawyer standpoint, Tuck's proposal is very attractive, and surely would be
+helpful to a number of users.  It makes the language more useful, more
+uniform, etc.
+
+But what is really needed here is a _business_ case.  This new feature would
+have a significant implementation cost.  So the question is not: would it
+help users?  Surely it would.  The question is: of all the possible
+extensions, is this among the most important ones?  In other words: would
+Thomas be able to convince his compiler vendor (whoever that is) to
+implement the feature?
+
+The ARG cannot ignore that new features have a significant opportunity cost:
+if a vendor decides to implement an extension, they won't be doing other
+work to improve the usability of their compiler/environment.  The Ada market
+being what it is, I don't see vendors increasing significantly their R&D
+expenses just to keep up with the extensions that the ARG is coming up with.
+Each time we discuss an extension, we must carefully weight the costs and
+the benefits, and ask ourselves if what we are doing is the best for the Ada
+community.
+
+> More significantly, is to find at least one vendor who is willing to
+> champion this extension. Right now, speaking for Ada Core Technologies,
+> we do not see a customer demand for this feature -- of course that can
+> always change in the future.
+
+Speaking for Rational, this issue has been mentioned as an annoyance a
+number of times by customers, but I don't think that at this point we would
+see it as a priority.  (As you say, this could change.)
+
+****************************************************************
+
+From: Thomas Wolf
+Sent: Thursday, December 14, 2000 2:13 AM
+
+> Similarly, the AI is missing an example; I left Tucker's there. We discussed
+> at the ARG meeting that proposals ought to be accompanied by examples of use
+> (and if possible, a test program -- the latter is premature). In theory, I'm
+> supposed to reject proposals without them -- so, Steve, et. al., please
+> update Tucker's example appropriately (or construct a new one).
+
+These examples are in the ASCII version of the Wellings et. al.
+TOPLAS paper, which should be in the appendices of this AI.
+(Steve's message entitled "AI on EPT - appendix 2".)
+
+****************************************************************
+
+From: Ted Baker
+Sent: Thursday, December 14, 2000 7:23 AM
+
+I agree that adding inheritance to protected types has no strong
+business case that I know of, and that in general, additions to
+the language will need a strong business case to justify the cost
+to implementors.  I don't think we will get more people to use Ada
+for real commercial projects, or to teach it, by adding more bells.
+(One possible exception being the multiple inheritance issue
+brought up by Tucker.)  On the other hand, we can kill what remains
+of the Ada market by forcing implementors to break their implementations
+by adding a bunch of new features, which could either bankrupt the
+implementors or cause them to turn out buggy new releases to support
+the new features.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, December 14, 2000 7:59 AM
+
+<<brought up by Tucker.)  On the other hand, we can kill what remains
+of the Ada market by forcing implementors to break their implementations
+by adding a bunch of new features, which could either bankrupt the
+implementors or cause them to turn out buggy new releases to support
+the new features.
+>>
+
+Don't worry, ARG decisions about extensions will never force the
+implementors to do anything. The ARG is not in a position to mandate
+implementors to do anything. Neither for that matter is WG9.
+
+We have a language, Ada 95, which implementors provide. If the ARG
+figures out extensions, vendors will provide them if and only if
+they make money by doing so (i.e. capture more business, or can
+charge more or ...)
+
+If Ada 0X comes out, vendors may or may not implement it (same
+considerations apply -- purely commercial ones).
+
+My concern is not in killing the Ada market or causing problems for
+vendors, my concern is for wasting time in the ARG when it could
+be doing more useful things.
+
+****************************************************************
+
+From: Stephen Michell
+Sent: Thursday, December 14, 2000 9:20 AM
+
+I understand. The problem with such a feature, of course, is that 99% of all
+programs do not use concurrency in any meaningful way - and certainly don't
+use the Ada tasking model. On the other hand, if one is going to build
+embedded systems where the management of events is important and there is
+limited OS support for these things, then the Ada tasking mechanisms are very
+useful, and are used. Heck - SAAB uses full Ada tasking for the Gripen flight
+control system. Many such people were reluctant to consider OO in such systems
+even a few years ago, but are now considering its use in these systems.
+
+The EPT proposal addresses a significant disconnect between these paradigms
+which may encourage more people to use OO in embedded systems where
+concurrency is used.
+
+Of course the vendors know their customer base more than we, as non-vendors
+do, but I assume that they will not stand up and say that there is no interest
+in the community until they have had serious discussions with people that may
+be interested.
+
+In the end, if there is no interest, of course it will not get implemented. In
+the meantime, there is a fairly carefully thought through proposal for
+consideration, and there is a reference implementation being built. I would
+hope that folks would keep an open mind and see if the interest develops.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, December 14, 2000 8:59 AM
+
+<<I understand. The problem with such a feature, of course, is that 99% of all
+programs do not use concurrency in any meaningful way - and certainly don't
+use the Ada tasking model. On the other hand, if one is going to build
+>>
+
+THat's way way off, we find MOST of our customers using Ada tasking these
+days. Yes there are some exceptions, but if you are saying that in your
+environment 99% of programs do not use Ada tasking, then you are in
+a different world from most of our customers.
+
+<<In the end, if there is no interest, of course it will not get implemented.
+In the meantime, there is a fairly carefully thought through proposal for
+consideration, and there is a reference implementation being built. I would
+hope that folks would keep an open mind and see if the interest develops.
+>>
+
+I would wait till this reference implementation is built, and see how it
+works out in practice, and presumably this means that there is one vendor
+interested enough to push the idea, which is just fine.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, December 14, 2000 9:21 AM
+
+Just to follow up on SM's cclaim that 99% of programs do not use
+concurrency.
+
+One surprising thing we are finding is that even in the safety-critical
+market, there is a lot of demand for high level concurrency solutions.
+You also see this in Aonix's work in Raven, and WRS' work in producing
+a certified kernel with Raven-style tasking capability. Needless to say
+in the GNAT world, we DO see a commercial benefit in pursuing that line
+of action (and it should come as no surprise to find out that we are
+indeed doing so :-)
+
+****************************************************************
+
+From: Mike Kamrad
+Sent: Thursday, December 14, 2000 9:08 AM
+
+>My concern is not in killing the Ada market or causing problems for
+>vendors, my concern is for wasting time in the ARG when it could
+>be doing more useful things.
+
+What would those useful things be?  You have stated very clearly that the
+TC effort wasn't useful.  If the ARG doesn't weigh in on extensions, then
+what's left...m
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, December 14, 2000 9:18 AM
+
+er um .. who ever said that the ARG should not work on extensions. I have
+said repeatedly that I thought the most important item on the agenda was
+to finish off the work items on Unchecked_Union and recursive types!
+
+The fact that I am dubious about one particular extension should not be
+for a moment generalized in the above wrong direction.
+
+I think the MOST valuable thing for the ARG to do is to concentrate on
+extensions that DO meet the commercially important criterion. A very
+good measure of this is when at least one implementation (and in the
+case of unchecked union, several implementations) have gone off on
+their own and done something.
+
+Tuck's multiple inheritance proposal may be in this category too, have not
+had time to think about that -- anyway, let's finish off important old
+work before we embark on new :-)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, December 14, 2000 8:17 PM
+
+The good news here is that (IMHO) the technical work on the original three
+amendments is essentially done. Tucker still has to churn out RM-style
+wording for "with type" and "unchecked_union", but otherwise these are
+finished. Of course, implementing them may turn up additional technical
+problems. But they should be stable enough for implementors to look at them
+seriously. (Tucker and I both indicated that we would be doing so soon, I
+don't know if other implementors are.) [The three AIs I'm refering to are
+AI-216 (unchecked_union), AI-217 (with type), and AI-218 (pragma Overriding,
+etc.)] Probably the most likely way to find problems in these AIs is for
+implementors to try to implement them (remember the benefits that the U/I
+teams had on Ada 95?).
+
+Of course, wordsmithing on the AIs will probably take another couple of
+meetings to complete (but I know you don't find that particularly
+interesting).
+
+We still have other amendments to deal with (including the related access
+conversions AI which is needed to make "with type" more usable); but I think
+we can afford to cautiously look at other things. Still, we have to be
+careful not to take on so much at once that we make no progress on anything.
+
+****************************************************************

Questions? Ask the ACAA Technical Agent