CVS difference for ai12s/ai12-0092-1.txt

Differences between 1.9 and version 1.10
Log of other versions for file ai12s/ai12-0092-1.txt

--- ai12s/ai12-0092-1.txt	2015/01/31 01:45:26	1.9
+++ ai12s/ai12-0092-1.txt	2015/02/03 04:41:19	1.10
@@ -7176,6 +7176,24 @@
 
 ***************************************************************
 
+From: Robert Dewar
+Sent: Sunday, February  1, 2015  10:36 AM
+
+The question is whether SOME causes trouble in practice. If you have extensive
+use of SOME in a context where you can easily  press a button and change all
+uses to something else, then that's an example of SOME being used, perhaps
+extensively, but it's not an example of it causing real trouble in a real
+setting. Similarly, if you are talking about code that in practice is not used
+much in major projects, the impact may be minimal. At the time, I certainly
+judged Randy's report to be in these non-problematical categories.
+
+On the other hand a single use of SOME in a context where it is NOT easy to
+change (e.g. a standard mandated use, like CORBA.String) could be much more
+troublesome. That being said, so far I don't think AdaCore has encountered a
+troublesome problem with SOME.
+
+***************************************************************
+
 From: Randy Brukardt
 Sent: Friday, January 30, 2015  7:29 PM
 
@@ -8401,5 +8419,249 @@
 my part. Still, compilers have been creating such categories forever. I did it
 in the Eighties. If they are in the category "this will never work (as
 expected)", well, fine.
+
+***************************************************************
+
+From: Robert Dewar
+Sent: Sunday, February  1, 2015  10:32 AM
+
+> Anyway, I view "suppressible errors" as mainly useful for 
+> methodological restrictions, specifically cases where the construct 
+> has a strong probability of being a problem. (The declaration of some 
+> entity named Standard is one such example.) I'd say there has to be 
+> less than a 5% chance that the construct in question is not a problem 
+> in order for a suppresible error to apply.
+
+It is plain nonsense to say that using Standard as an entity name has a 95%
+chance of being a problem. I looked through the 22 uses of Standard as an
+entity in our test suite, and 100% of them seemed safe and reasonable to me.
+Please don't impose YOUR idiosyncratic views on the language.
+
+The language could have reserved the identifiers in Standard, but quite
+deliberately decided not to. Of course you can disagree with that decision,
+and for *your own code* restrict uses you don't like, but it is unreasonable
+to insist that your view is the only one that makes sense (reminds me of the
+anti-use fanatics who are quite sure that everyone writing Ada should avoid
+use clauses). Actually it is when you don't use USE clauses that reuse of
+standard entities makes sense, e.g. the CORBA Ada standard requires the
+definition of a type called String, and to me Corba.String reads very nicely,
+and coexists just fine with plain String to refer to the Ada standard String.
+
+That's what worries me about suppressible errors, they have a real potential
+for being a place where people's idiosyncratic views on things you should
+avoid can be deprecated.
+
+I really much prefer the dynamic in an implementation setting for choosing
+what to warn about. You see a report from a user who has done something that,
+while legal, is dubious and has caused trouble.
+
+You explain that the compiler is doing the right thing, but put on your
+thinking cap to wonder if the compiler could emit a useful warning. Here is
+an example of a recent addition to GNAT that has that kind of history:
+
+> NF-74-O107-022 Warn on use of pragma Import in Pure unit (2015-01-10)
+>
+>   The use of pragma Import in a Pure unit is worrisome since it can be used
+>   to "smuggle" non-pure behavior into a pure unit. This usage now generates
+>   a warning that calls to a subprogram imported in this manner may in some
+>   cases be omitted by the compiler, as allowed for Pure units. This warning
+>   is suppressed if an explicit Pure_Function aspect is given.
+
+***************************************************************
+
+From: Bob Duff
+Sent: Sunday, February  1, 2015  11:35 AM
+
+>....e.g. the CORBA Ada standard requires the definition of a type  
+>called String, and to me Corba.String reads very nicely, and coexists  
+>just fine with plain String to refer to the Ada standard String.
+
+That's fine for clients, but within Corba itself, it's a nuisance, because 
+Corba.String IS referred to as String, and Standard.String MUST be referred
+to as Standard.String.  I find that confusing when reading the sources,
+especially since the visibility is different in other parts of PolyORB.
+
+> That's what worries me about suppressible errors, they have a real 
+> potential for being a place where people's idiosyncratic views on 
+> things you should avoid can be deprecated.
+
+Well, it's much worse when people's idiosyncratic views make it into the
+language as (hard) legality rules, which has happened.  Or when those views
+distort the language design ("We don't have to worry about X, because nobody
+should be using X", which is fine if there's universal agreement about X, but
+not otherwise).
+
+> I really much prefer the dynamic in an implementation setting for 
+> choosing what to warn about. You see a report from a user who has done 
+> something that, while legal, is dubious and has caused trouble.
+> 
+> You explain that the compiler is doing the right thing, but put on 
+> your thinking cap to wonder if the compiler could emit a useful 
+> warning. Here is an example of a recent addition to GNAT that has that 
+> kind of history: ...
+
+Nothing wrong with that dynamic, but:
+
+There is some value in having standardization, at least for some such cases.
+There should be no implication that RM rules are "more important" than
+compiler-specific warnings.  In fact it is already the case that (some)
+compiler-specific warnings (e.g. uninit vars) are more important than (some)
+RM rules (e.g. some obscure accessibility case that only comes up in Bairdian
+examples).
+
+ARG has historically gotten into huge arguments, where we have a useful
+proposal, but some folks insist on legality rules, but those are incompatible,
+so we end up dropping the useful proposal, or we end up with incompatibilities,
+or we end up with an inferior alternative proposal.  Suppressible errors are
+intended to defuse those arguments.
+
+Consider 'in out' parameters on functions, which tooks decades to get into the
+language, and only after deferring to Tucker's insistence on some legality
+rules (which turned out to be incompatible).
+
+***************************************************************
+
+From: Robert Dewar
+Sent: Sunday, February  1, 2015  2:34 PM
+
+> That's fine for clients, but within Corba itself, it's a nuisance, 
+> because Corba.String IS referred to as String, and Standard.String 
+> MUST be referred to as Standard.String.  I find that confusing when 
+> reading the sources, especially since the visibility is different in 
+> other parts of PolyORB.
+
+Seems bad style indeed, I would always use Corba.String within Corba itself.
+Within Corba itself, my recommmendation  would be to ALWAYS qualify stsring
+to prevenet any confusion.
+
+Maybe *that* should be what causes a warning, referring  to an entity with
+the same name as a standard entity without qualification.
+
+> Well, it's much worse when people's idiosyncratic views make it into 
+> the language as (hard) legality rules, which has happened.  Or when 
+> those views distort the language design ("We don't have to worry about 
+> X, because nobody should be using X", which is fine if there's 
+> universal agreement about X, but not otherwise).
+
+Strongly agree with this, for instance the incompatible business with
+overlapping  parameters, which  does cause customers trouble with error false
+positives, should have been a suppressible error.
+
+> There is some value in having standardization, at least for some such 
+> cases.  There should be no implication that RM rules are "more 
+> important" than compiler-specific warnings.  In fact it is already the 
+> case that (some) compiler-specific warnings (e.g. uninit vars) are 
+> more important than (some) RM rules (e.g. some obscure accessibility 
+> case that only comes up in Bairdian examples).
+
+I am dubious about  there being some value in this
+>
+> ARG has historically gotten into huge arguments, where we have a 
+> useful proposal, but some folks insist on legality rules, but those 
+> are incompatible, so we end up dropping the useful proposal, or we end 
+> up with incompatibilities, or we end up with an inferior alternative 
+> proposal.  Suppressible errors are intended to defuse those arguments.
+> Consider 'in out' parameters on functions, which tooks decades to get 
+> into the language, and only after deferring to Tucker's insistence on 
+> some legality rules (which turned out to be incompatible).
+
+Yes, good point, and, as above, good example!
+
+***************************************************************
+
+From: Robert Dewar
+Sent: Sunday, February  1, 2015  2:47 PM
+
+> Maybe *that* should be what causes a warning, referring  to an entity 
+> with the same name as a standard entity without qualification.
+
+In fact I am tempted to try that one and see how many violations,
+
+   warning: "String" refers to non-standard declaration at ....
+
+or
+
+   warning: "String" refers to Corba.String
+
+I think I will test that out :-)
+
+***************************************************************
+
+From: Robert Dewar
+Sent: Sunday, February  1, 2015  2:51 PM
+
+One point here also is that it is hard to imagine a case in practice where a
+suppressible error was defined, and GNAT found the warning so troublesome as
+to be troublesome EVEN under a special switch.
+
+Note that similar stuff has happened before in the context of obsolete stuff,
+where including the old pragmas/attributes as obsolescent in pragma
+Restrictions (No_Obsolescent_Features) caused major incompatibilities, and
+GNAT just refuses to make this inclusion (can't remember if this is now
+allowed by the RM or not, but it would not affect the GNAT decision).
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Monday, February  2, 2015  8:41 PM
+
+> > Anyway, I view "suppressible errors" as mainly useful for 
+> > methodological restrictions, specifically cases where the construct 
+> > has a strong probability of being a problem. (The declaration of 
+> > some entity named Standard is one such example.) I'd say there has 
+> > to be less than a 5% chance that the construct in question is not a 
+> > problem in order for a suppresible error to apply.
+> 
+> It is plain nonsense to say that using Standard as an entity name has 
+> a 95% chance of being a problem. I looked through the 22 uses of 
+> Standard as an entity in our test suite, and 100% of them seemed safe 
+> and reasonable to me. Please don't impose YOUR idiosyncratic views on 
+> the language.
+
+Why do you think this is about me? This is just an example, and one that
+appears to have a consensus during previous discussions. It SURELY isn't
+about me -- anything that gets made a suppressible error would have to have
+a consensus of the ARG. 
+
+The only thing about me here is the "95%", which is an approximation of the
+criteria that I would use for determining what I think should be (or not be)
+a suppressible error. If one doesn't have a criteria, then it just becomes
+random selection, and that would be a terrible way to do language design.
+
+...
+> That's what worries me about suppressible errors, they have a real 
+> potential for being a place where people's idiosyncratic views on 
+> things you should avoid can be deprecated.
+
+Yup.  I'd hope that we could come to some sort of consensus on the criteria
+for what is a suppressible error. Without that, the whole idea is just going to
+turn into a quagmire.
+
+> I really much prefer the dynamic in an implementation setting for 
+> choosing what to warn about. You see a report from a user who has done 
+> something that, while legal, is dubious and has caused trouble.
+> 
+> You explain that the compiler is doing the right thing, but put on 
+> your thinking cap to wonder if the compiler could emit a useful 
+> warning. Here is an example of a recent addition to GNAT that has that 
+> kind of history:
+> 
+> > NF-74-O107-022 Warn on use of pragma Import in Pure unit 
+> > (2015-01-10)
+> >
+> >   The use of pragma Import in a Pure unit is worrisome since it can be used 
+> >   to "smuggle" non-pure behavior into a pure unit. This usage now generates
+> >   a warning that calls to a subprogram imported in this manner may in some
+> >   cases be omitted by the compiler, as allowed for Pure units. This warning
+> >   is suppressed if an explicit Pure_Function aspect is given.
+
+I'd guess that you'd have trouble getting consensus on this being a
+suppressible error, given that when I raised this issue years ago I was told
+that it is an important loophole into making Pure units usable in practice
+(such as debugging them).
+
+If all we're going to do is argue about what errors should be suppressible,
+and then confuse them with warnings, the whole idea starts to look like a
+waste of time.
 
 ***************************************************************

Questions? Ask the ACAA Technical Agent