Re: Range constraints on subprogram parameters?

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"Randy Brukardt" <randy@rrsoftware.com> 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