CVS difference for ais/ai-00230.txt

--- ais/ai-00230.txt	2001/10/02 01:27:51	1.3
+++ ais/ai-00230.txt	2001/10/02 20:50:32	1.4
@@ -1288,5 +1288,363 @@
 
 *************************************************************
 
+From: Robert Dewar
+Sent: Monday, October 1, 2001  8:27 PM
 
+<<My own guess is that is going to be hard to come by on this one. This
+proposal grew out an attempt to save "with type"; now that that has been
+scuttled, the need for this one is much less compelling.>>
+
+The important thing to realize about proposals for additions is that the
+dynamics have in my view shifted completely. In the old days, the ARG
+could via WG9 and ACATS essentially command all implementors to implement
+feature X and they had to jump.
+
+Now, at least speaking for ACT, but I suspect for other vendors too, the
+issue of whether new features get implemented is far more dependent on
+what real customers want. If a new feature is approved, or even "mandated"
+it will not get implemented unless customers need/want it implemented and
+resources are consequently available.
+
+That's why it is so important to make sure that real demand exists before
+we sit around designing neat features that would be nice to have.
+
+*************************************************************
+
+From: Tucker Taft
+Sent: Monday, October 1, 2001 11:29 PM
+
+Randy Brukardt wrote:
+> ...
+> > The important thing here is that the justification include some evidence
+> > that this is a real world issue, i.e. a purely technical nice-to-have
+> > justification is dubious. We need some real world examples or input.
+>
+> My own guess is that is going to be hard to come by on this one. This
+> proposal grew out an attempt to save "with type"; now that that has been
+> scuttled, the need for this one is much less compelling.
+
+I don't see that as the primary justification.  The major
+need relates to the large number of unnecessary explicit
+conversions when using Ada 95 for "normal" OO-style
+programming.  The connection with "with type" was pretty
+remote, in my view.
+
+>
+> At least, this proposal gets rid of the run-time accessibility for every
+> object that we had discussed at the last meeting. But I'm still concerned
+> that static accessibility might not be enough to implement this (especially
+> in shared generics, where the static level /= instantiation level).
+>
+> If I ever get some spare time, I'll have to think about this one some more.
+
+In thinking about this more, I have concluded that we should allow
+access_definitions in component subtype indications, but with the
+same rules as for discriminants, namely that the accessibility level
+of the anon subtype is the same as the level of the enclosing composite
+object.  This jibes with the fact that typically a set of objects that
+point at each other all have the same lifetime.
+
+I didn't adequately deal with allocators.  I think if an allocator appears
+as the expression of a return statement, where the return type is specified
+using an access_definition, then the storage pool to use for the allocator
+is determined by the caller.  This creates a very useful capability for
+a function to do an allocation in a storage pool determined by context.
+This is a fundamental requirement for region-based memory allocation,
+which is becoming recognized as the "thinking person's alternative" to
+full garbage collection.  This argues for a uniform treatment of
+such functions, namely that they are implicitly passed both the "caller"
+accessibility level and the target storage pool for allocators.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, October 2, 2001  5:22 AM
+
+
+<<I don't see that as the primary justification.  The major
+need relates to the large number of unnecessary explicit
+conversions when using Ada 95 for "normal" OO-style
+programming.  The connection with "with type" was pretty
+remote, in my view.
+>>
+
+That's one level remote to me, I need a "major need" to be expressed
+in terms of actual people writing actual code with actual needs and
+examples.
+
+I am afraid that the ARG is trying to take on the job of requirements
+gathering for language enhancements without sufficient connection to
+the outside world. We haven't even asked *vendors* what they think is
+important, let alone asking actual Ada users. Language designers are
+not the right people to be deciding on what is really important to
+add.
+
+For example, if you were to ask ACT what the single most important
+feature needed was, I suspect it would be C++ interfacing features.
+I certainly can't remember any customer asking about "large number
+of unnecessary explicit conversions" :-)
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, October 2, 2001 1:18 PM
+
+> I am afraid that the ARG is trying to take on the job of requirements
+> gathering for language enhancements without sufficient connection to
+> the outside world. We haven't even asked *vendors* what they think is
+> important, let alone asking actual Ada users.
+
+Many vendors participate in this group, and have rarely been shy about
+expressing their views. Certainly, ACT has been happy to provide this at every
+opportunity. :-)
+
+But I would caution against using requests to vendors as the only criteria. The
+Ada community has a strong commitment to following standards, and thus I would
+not expect most customers to ask their vendor to "break" the standard.
+Therefore, I'd expect enhancement requests to vendors to involve areas outside
+of the standard (interfacing to other languages, additional provided packages,
+performance issues, etc.), and most of that isn't interesting to the ARG any.
+
+To take a specific example. When we were building Claw, we wasted a lot of time
+tracking down "bugs" caused by broken overridding (where we thought some
+routine was overridding, but wasn't due to a spelling error or missing
+parameter). We didn't run to a vendor (even though I probably could have
+convinced one to do something :-) to fix this: we just put it down to bad
+language design and lived with it. The only thing we did is mention it toward
+the end of our paper on Claw. Only when I wrote up an amendment AI on the topic
+(mainly to provide a fully fleshed out example AI to get comments on the format
+of an amendment) did I find out that many other people shared this frustration.
+I doubt anyone ran to ACT to ask for an enhancement here (although they might
+now that there is a fully defined solution).
+
+> Language designers are not the right people to be deciding on what is
+> really important to add.
+
+This is true, but I would argue that the majority of the ARG membership aren't
+"language designers" per se, but vendors and/or users of Ada. Of course,
+everyone is a "language designer" from time-to-time.
+
+> I need a "major need" to be expressed
+> in terms of actual people writing actual code with actual needs and
+> examples.
+
+For this particular AI, I certainly agree. So far as I remember, the problem
+was driven by complaints from Erhard's students. While these are "actual
+people", I have my doubts that they meet the "actual needs" qualification.
+Moreover, we built Claw (certainly a large O-O system) without running into
+this problem. I would much rather have "in out" parameters on functions (as
+that would fix a real problem that we have had with O-O programs) than this
+proposal [access parameters are not a real replacement for "in out" parameters,
+as the calls are much more complex].
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, October 2, 2001  1:44 PM
+
+<<Many vendors participate in this group, and have rarely been shy about
+expressing their views. Certainly, ACT has been happy to provide this at
+every opportunity. :-)>>
+
+There is a different between having some technical person participating
+in the ARG meetings, and getting formal input from vendors.
+
+<<But I would caution against using requests to vendors as the only criteria.
+The Ada community has a strong commitment to following standards, and thus I
+would not expect most customers to ask their vendor to "break" the standard.
+Therefore, I'd expect enhancement requests to vendors to involve areas
+outside of the standard (interfacing to other languages, additional provided
+packages, performance issues, etc.), and most of that isn't interesting to
+the ARG any.>>
+
+The ARG should be more interested in such issues. yes, I know it is more
+fun for language designers to design neat new features -- and that's my
+point.
+
+Surely we should not use requests to vendors as the only criterion, but
+it's a better sole criterion than using the input from language designers
+as the only criterion.
+
+In fact we get a wide variety of requests from customers, after all,
+WITH TYPE is there because customers needed it, not because there was
+some AI suggesting it, as an example.
+
+<<Only when I wrote up an amendment AI on the topic (mainly to provide a fully
+fleshed out example AI to get comments on the format of an amendment) did I
+find out that many other people shared this frustration. I doubt anyone ran
+to ACT to ask for an enhancement here (although they might now that there is
+a fully defined solution).
+>>
+
+Remember that in our environment, customers ask us if they have any
+questions or problems whatsoever in using Ada. All the time, they
+are asking us "how do we do this in Ada", or "can't we find a better
+way of doing things than this". So indeed we have lots of input of
+this kind, but I can't find many things that would be worth new language
+features.
+
+Right now, I think there is a real danger of designing language features
+that no one will implement, and thus making an updated standard irrelevant.
+
+<<For this particular AI, I certainly agree. So far as I remember, the problem
+was driven by complaints from Erhard's students. While these are "actual
+people", I have my doubts that they meet the "actual needs" qualification.
+Moreover, we built Claw (certainly a large O-O system) without running into
+this problem. I would much rather have "in out" parameters on functions (as
+that would fix a real problem that we have had with O-O programs) than
+proposal [access parameters are not a real replacement for "in out"
+parameters, as the calls are much more complex].
+>>
+
+The lack of in out parameters in functions, a restriction that as far as
+I can tell is, like the peculiar declaration ordering rules in 83, there
+only because someone thinks it is more consistent with some particular
+coding philosophy (*), is indeed a significant problem.
+
+Robert Dewar
+
+(*) I continue to find it odd that the design principle for functions in
+the Ada language is "functions can have arbitrary side effects, but no
+hint of this is allowed in the function specification. If you want to
+make a state change in a function, it cannot be done using IN OUT
+parameters in the spec, instead it must be done covertly using global
+variables" :-)
+
+*************************************************************
+
+From: Dan Eilers
+Sent: Tuesday, October 2, 2001  2:13 PM
+
+Robert Dewar wrote:
+
+> (*) I continue to find it odd that the design principle for functions in
+> the Ada language is "functions can have arbitrary side effects, but no
+> hint of this is allowed in the function specification. If you want to
+> make a state change in a function, it cannot be done using IN OUT
+> parameters in the spec, instead it must be done covertly using global
+> variables" :-)
+
+Well, to some extent, declaring a global variable is an overt invitation
+for modification by any code within its scope.  The covertness problem
+with IN OUT parameters on functions is that there is no indication at
+the point of the call that parameters might be modified, where such
+parameters are likely to be local variables with no signal to the
+reader that they are modified by the function call.  I believe this
+problem was pointed out in C.A.R. Hoare's famous 1973 paper "Hints
+on Programming Language Design".
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, October 2, 2001  3:08 PM
+
+Which of course applies equally to procedure calls. And I have been
+occassionally surprised by procedures modifying parameters, and it would be
+nice if that was identified in the call. But it seems about 20 years too late
+to complain about that...
+
+*************************************************************
+
+From: Dave Emery
+Sent: Tuesday, October 2, 2001  2:10 PM
+
+At 14:44 -0400 10/2/01, dewar@GNAT.COM wrote:
+>...
+>The lack of in out parameters in functions, a restriction that as far as
+>I can tell is, like the peculiar declaration ordering rules in 83, there
+>only because someone thinks it is more consistent with some particular
+>coding philosophy (*), is indeed a significant problem.
+
+Can I vote for reconsidering/removing this (stupid) restriction?
+
+If one argument in favor of keeping it is to allow the compiler
+or some third-party verification tool to assume or to check
+that the function has no side-effects, I'd rather do that
+check with a pragma, and allow/trust the user to do the
+right thing at the right time.  Certainly this has been
+a very painful restriction for interfacing with other languages
+that do not accept this point of dogma :-)
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, October 2, 2001  3:03 PM
+
+> The ARG should be more interested in such issues. yes, I know it is more
+> fun for language designers to design neat new features -- and that's my
+> point.
+
+I understand, but in practice, there haven't been much in the way of expanding
+the language. When I proposed the Ada.Directories package, there was a lot of
+opposition of "not important enough" (and you originally led the charge on
+that). As far as C++ interfacing goes, we discussed this at the Westboro
+meeting (September 1999), but no one had any proposals on what to do. The
+existing work was all rather implementation-dependent. (Ed was at that meeting,
+and presented various GNAT features to the group, but I don't recall if he was
+there for this discussion.) And so far as I know, nothing has been proposed
+since.
+
+
+> Remember that in our environment, customers ask us if they have any
+> questions or problems whatsoever in using Ada. All the time, they
+> are asking us "how do we do this in Ada", or "can't we find a better
+> way of doing things than this". So indeed we have lots of input of
+> this kind, but I can't find many things that would be worth
+> new language features.
+
+I also get questions of the sort of "how do you do X?", but I'm never thinking
+about new language features when I answer them. "Wait until 2006" doesn't seem
+likely to satisfy many customers!
+
+> Right now, I think there is a real danger of designing language features
+> that no one will implement, and thus making an updated standard irrelevant.
+
+Understandable, and AI-230 is certainly a possible offender in this area.
+
+> The lack of in out parameters in functions, a restriction that as far as
+> I can tell is, like the peculiar declaration ordering rules in 83, there
+> only because someone thinks it is more consistent with some particular
+> coding philosophy (*), is indeed a significant problem.
+
+I've always figured that I should have the power to re-open this issue, as I
+was one of the people who fought tooth-and-nail to keep it in Ada 95. The main
+reason is that the Janus/Ada intermediate code does not allow copy-back for
+function calls -- and changing this would be a very large change to the
+optimizer and code generator. (Function calls always discard their parameters.)
+
+My mind was changed by our work on Claw. The first problem was a query
+function:
+
+    function Is_Something (Window : in Root_Window_Type) return Boolean is
+    begin
+       -- Long calculation involving several system calls.
+       return Answer;
+    end Is_Something;
+
+Is_Something (I forget the exact function involved) was likely to be called
+frequently, so I wanted to save the result I calculated in the Window object.
+So I added a component to save the value and a component to say whether the
+first component was, and got a compile-time error trying to set them. Ugh.
+
+The problem has occurred repeatedly during the development of Claw. Some
+operations that we would have preferred to be functions ended up as procedures
+since we needed to modify the object. On a few occasions, we used the fact that
+Claw objects are assignable, and "clones" of each other to work around the
+problem:
+
+   function Is_Something (Window : in Root_Window_Type) return Boolean is
+       Writable_Copy : Root_Window_Type'Class := Window;
+   begin
+       -- Modify components of Writable_Copy, which modifies the original object.
+       return Answer;
+   end Is_Something;
+
+But that is horrible (and inefficient).
+
+I've tried to raise the "in out" issue at the ARG meetings without success.
+People are afraid that the same old bunch of opponents (minus at least one --
+me!) would resurface.
+
+*************************************************************