Range constraints on subprogram parameters?

Range constraints on subprogram parameters?

[Bobby D. Bryant]

Is it possible to specify range constraints for subprogram parameters?

E.g., if you want to require a floating point value in the range [0,1].

Thanks,
-- 
Bobby Bryant
Austin, Texas

Re: Range constraints on subprogram parameters?

[Jeffrey R. Carter]

Bobby D. Bryant wrote:
> Is it possible to specify range constraints for subprogram parameters?
> 
> E.g., if you want to require a floating point value in the range [0,1].

Of course:

type Zip_2_1 is digits 6 range 0.0 .. 1.0;

procedure Op (Number : in Zip_2_1);

-- 
Jeff Carter
"What I wouldn't give for a large sock with horse manure in it."
Annie Hall
42

Re: Range constraints on subprogram parameters?

[Peter Hermann]

Jeffrey R. Carter <spam@spam.com> wrote:
> Bobby D. Bryant wrote:
> > Is it possible to specify range constraints for subprogram parameters?
> > 
> > E.g., if you want to require a floating point value in the range [0,1].
> 
> Of course:
> 
> type Zip_2_1 is digits 6 range 0.0 .. 1.0;
> 
> procedure Op (Number : in Zip_2_1);

procedure Op (Number : in Zip_2_1 range 0.3 .. 0.7);

may have been the original question?

-- 
--Peter Hermann(49)0711-685-87244            ihrph@ihr.uni-stuttgart.de
--Nobelstr.19 Raum 0.030, D-70569 Stuttgart IHR Hoechstleistungsrechnen
--http://www.csv.ica.uni-stuttgart.de/homes/ph/       external fax-3644

Re: Range constraints on subprogram parameters?

[Martin Dowie]

Peter Hermann wrote:
> procedure Op (Number : in Zip_2_1 range 0.3 .. 0.7);
>
> may have been the original question?

In that case the answer is easy : NO! :-)

Cheers

-- Martin

Re: Range constraints on subprogram parameters?

[Jeffrey R. Carter]

Peter Hermann wrote:

> procedure Op (Number : in Zip_2_1 range 0.3 .. 0.7);
> 
> may have been the original question?

Maybe. If so, no doubt we will hear back with a clarification. But the question 
was about range constraints for subprogram parameters, and Ada does provide for 
them, in the form of the subtypes of the parameters.

-- 
Jeff Carter
"There's no messiah here. There's a mess all right, but no messiah."
Monty Python's Life of Brian
84

Re: Range constraints on subprogram parameters?

[Bobby D. Bryant]

On Thu, 29 Sep 2005, Peter Hermann <ica2ph@csv.ica.uni-stuttgart.de> wrote:

> Jeffrey R. Carter <spam@spam.com> wrote:
>> Bobby D. Bryant wrote:
>> > Is it possible to specify range constraints for subprogram parameters?
>> > 
>> > E.g., if you want to require a floating point value in the range [0,1].
>> 
>> Of course:
>> 
>> type Zip_2_1 is digits 6 range 0.0 .. 1.0;
>> 
>> procedure Op (Number : in Zip_2_1);
> 
> procedure Op (Number : in Zip_2_1 range 0.3 .. 0.7);
> 
> may have been the original question?

Yes, that's what I was wanting.

It occurs to me in retrospect that it would be problematic from a
language design perspective, since it would be impossible to enforce
at compile time.

Thanks to everyone who replied.

-- 
Bobby Bryant
Austin, Texas

Re: Range constraints on subprogram parameters?

[Bobby D. Bryant]

On Thu, 29 Sep 2005, "Jeffrey R. Carter" <spam@spam.com> wrote:

> Bobby D. Bryant wrote:
>> Is it possible to specify range constraints for subprogram parameters?
>> 
>> E.g., if you want to require a floating point value in the range [0,1].
> 
> Of course:
> 
> type Zip_2_1 is digits 6 range 0.0 .. 1.0;
> 
> procedure Op (Number : in Zip_2_1);

Thanks; I had missed that feature.  It's not what I need right now, but
I may be able to use it for some related problems.

-- 
Bobby Bryant
Austin, Texas

Re: Range constraints on subprogram parameters?

[Jeffrey R. Carter]

Bobby D. Bryant wrote:
> Yes, that's what I was wanting.
> 
> It occurs to me in retrospect that it would be problematic from a
> language design perspective, since it would be impossible to enforce
> at compile time.

It doesn't have to be enforceable at compile time, since subtype constraints 
don't have to be static:

procedure Outer (Max : in Positive) is
    subtype Num is Positive range 1 .. Max;

    procedure Inner (X : in Num) is

is perfectly legal.

It mostly depends on where the subprogram is declared compared to where the 
constraints are known.

-- 
Jeff Carter
"There's no messiah here. There's a mess all right, but no messiah."
Monty Python's Life of Brian
84

Re: Range constraints on subprogram parameters?

[Randy Brukardt]

"Jeffrey R. Carter" <spam@spam.com> wrote in message
news:yi4%e.5290$oc.213@newsread2.news.pas.earthlink.net...
> Bobby D. Bryant wrote:
> > Yes, that's what I was wanting.
> >
> > It occurs to me in retrospect that it would be problematic from a
> > language design perspective, since it would be impossible to enforce
> > at compile time.
>
> It doesn't have to be enforceable at compile time, since subtype
constraints
> don't have to be static:
>
> procedure Outer (Max : in Positive) is
>     subtype Num is Positive range 1 .. Max;
>
>     procedure Inner (X : in Num) is
>
> is perfectly legal.
>
> It mostly depends on where the subprogram is declared compared to where
the
> constraints are known.

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.
       ...

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.

Note that declaring the subtype explicitly (and separately) doesn't have
this problem.

                         Randy.

Re: Range constraints on subprogram parameters?

[Jeffrey R. Carter]

Randy Brukardt wrote:

> 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?

Now you're talking about some language other than Ada. The reason you can't have 
subtype constraints in a parameter declaration is because Ada doesn't allow them 
:) I'm sure you could design a language that does allow them, though your 
example makes it hard to see how the language could also have separate 
specifications and bodies.

> 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.

Reminds me of index expressions in FORTRAN 66: some operations were permissible 
and others not, with the effect that they were generally avoided all together. 
Requiring subtype constraints to be static in some cases and not in others might 
result in something similar.

-- 
Jeff Carter
"Now go away or I shall taunt you a second time."
Monty Python & the Holy Grail
07

Re: Range constraints on subprogram parameters?

[Robert A Duff]

"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

Re: Range constraints on subprogram parameters?

[Robert A Duff]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> 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.)

On the third hand, default expressions are not evaluated during
elaboration of the spec, nor during elaboration of the body -- they're
evaluated on every call.  Is _that_ confusing?

- Bob