CVS difference for acs/ac-00157.txt

Differences between 1.2 and version 1.3
Log of other versions for file acs/ac-00157.txt

--- acs/ac-00157.txt	2008/01/22 06:18:46	1.2
+++ acs/ac-00157.txt	2008/03/06 03:36:28	1.3
@@ -497,6 +497,116 @@
+From: Robert A. Duff
+Date: Tuesday, January 15, 2008  8:10 AM
+> I can understand the "programmer beware" attitude, ...
+First, I'm only half-heartedly advocating that attitude.
+Second, the reason I'm advocating it is that I don't know
+how to define the rules without (1) major additional features added,
+and (2) a lot of language design work.
+>...but what bothers me is
+> that it leaves no chance for the compiler to help. Unless the functions used
+> here are marked somehow, the compiler has no chance of detecting the
+> potential problems (and producing either warnings or errors). That's how
+> languages like C work, it doesn't seem Ada-like.
+The argument "C does it that way, so it must be wrong" is a falacy.
+I must admit, I've used that falacy myself.  ;-)
+I suggest we try to avoid it!
+> Ive heard it said that a separate static analysis tool should be doing this
+> checking, not the compiler. But I don't buy that: separate tools don't get
+> run by a lot of projects.
+I don't buy it, either, but I think your reason is wrong.  If there's a magical
+separate tool that can solve the problem, I have little sympathy for people who
+can't be bothered to use it.
+My problem with the "separate tool" idea is that it's an excuse to avoid
+solving hard problems.  If we don't know how to solve the problem using Ada
+rules, then separate tools won't solve it either.  Furthermore, there will be
+no portability -- i.e. no agreement on what exactly such a tool should
+require.  And no easy way to understand what class of bugs is guaranteed to be
+detected by such tools.
+>... After all, that's what C programmers say about C
+> ("just run Lint to check your programs, the compiler doesn't have to").
+If there's a 'lint' standard with wide acceptance that actually prevents a
+well-understood class of bugs, and that can be implemented efficiently, then I
+think that's an acceptable solution.  But then, if I were writing a C compiler,
+I'd probably make that 'lint' part of the compiler front end!
+> disagrees with that notion and builds that checking into the language. Why
+> is this different??
+> The whole point of this functionality is to detect errors earlier. If it is
+> introducing errors, it's not really helping.
+> ...
+> >     type Sequence is private;
+> >
+> >     subtype Empty_Sequence is Sequence;
+> >     pragma Constraint (Empty_Sequence, Is_Empty(Empty_Sequence));
+> >
+> >     subtype Non_Empty_Sequence is Sequence;
+> >     pragma Constraint (Non_Empty_Sequence, not
+> Is_Empty(Non_Empty_Sequence));
+> >
+> > I'd prefer not to have to write a Not_Is_Empty function, here.
+> This sort of "special visibility" is one of the things that I detest
+> intensely about these various proposals. It would be very difficult and
+> time-consuming to implement (there surely is no provision for special
+> visibility in pragmas or anywhere else for that matter now), and it would
+> potentially be very confusing to users (which kind of scope would you be in?
+> How would you remember?), and it would seem to introduce new possibilities
+> for anomolies.
+I think you overestimate the implementation difficulty.  Robert has already
+implemented this (or at least partly) in GNAT, and it doesn't seem like a big
+There are already similar things in Ada.  For example, a record rep clause has
+visibility as if it were inside the record.  For that matter, spec/body and
+child/private features already require the compiler to restore the visibility
+context to a previously saved state.
+> Ada does not allow double constraints in general (it does for elementary
+> types, but not for composite types). So I don't think double constraints can
+> be allowed here.
+> My view is that "range -10..10" is just a shorthand for a constraint
+> function
+>          function A_Range (Obj : in T) return Boolean is
+>          begin
+>              return Obj in -10..10;
+>          end A_Range;
+I don't think that analogy quite works, because if I says "subtype S is T range
+1..100;" or "type S is new T range 1..100;", I get a constraint error, because
+100 > 10.  The new constraint does not replace the old (unless of course you
+say T'Base).
+Not sure what the right answer is, here.
+> Moreover, my ideal goal would be for this to be first-class syntax (not an
+> attribute):
+Fine, but we're talking about something AdaCore is thinking about implementing
+in the near-to-medium term, whereas Ada won't standardize it until the long
+term.  And AdaCore doesn't want to invent a bunch of new syntax.
+To put it another way, saying "it has to be syntax" is making the best the
+enemy of good-enough (even though I agree that new syntax would be more
+aesthetically pleasing).
 From: Randy Brukardt
 Date: Tuesday, January 15, 2008  2:10 PM

Questions? Ask the ACAA Technical Agent