From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,1552407353207252 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news.glorb.com!newscon02.news.prodigy.com!newscon06.news.prodigy.com!prodigy.net!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Range constraints on subprogram parameters? Date: 01 Oct 2005 10:36:34 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1128177394 28108 192.74.137.71 (1 Oct 2005 14:36:34 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Sat, 1 Oct 2005 14:36:34 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: g2news1.google.com comp.lang.ada:5324 Date: 2005-10-01T10:36:34-04:00 List-Id: "Randy Brukardt" writes: > Actually, Bobby was correct. The reason you can't have subtype constraints > in a parameter declaration is because they aren't required to be static. The > problem is one of conformance when you have separate specifications and > bodies. If F is an integer-returning function that returns 1 the first time > it is called, 2 the second tine, and so on, what is the range of the > parameter P? > > procedure Ugh (P : in Integer range 0 .. F); -- F = 1. > > Obj : constant Integer := F; -- Call on F = 2. > > procedure Ugh (P : in Integer range 0 .. F) is -- F = 3. > ... I don't see a big problem here. One solution would be to say F is evaluated as part of the elaboration of the spec. This would make the run-time semantics exactly equivalent to the corresponding legal Ada program -- the one with a named subtype. Elaboration of the body would not call F. (Of course, if there's no explicit spec, you need to elaborate an implicit one at the place of the body.) I believe pre-1983 versions of Ada allowed the above. I suppose it was disallowed because the rules about when F gets evaluated might be confusing to programmers. > This is why Ada 200Y allows null exclusions in parameters: because they > always have to be static. We talked a bit aboult allowing static constraints > in subprogram parameter declarations, but didn't do it because that seemed > even more arbitrary than not allowing them at all. Yeah, that's another possible solution. I don't find this arbitrariness so bad -- there's a reason for it. After all, Ada has lots of seemingly-arbitrary rules requiring staticness. For example: type T1 is range 1..X; -- X must be static subtype T2 is Integer range 1..Y; -- Y need not be static Why? I'm generally in favor of rules that allow the programmer to avoid cluttering the namespace. On the other hand, I'm not sure that allowing constraints in the procedure spec would really be useful in practise. If you have a range constraint, the client is likely to want to declare variables with that same constraint, so you would normally want a name for it. Can anybody think of a counterexample? > Note that declaring the subtype explicitly (and separately) doesn't have > this problem. - Bob