From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 required=3.0 tests=BAYES_05,FREEMAIL_FROM
	autolearn=ham autolearn_force=no version=3.4.5-pre1
X-Received: by 2002:a05:620a:78b:: with SMTP id 11mr26777015qka.0.1615837074217;
        Mon, 15 Mar 2021 12:37:54 -0700 (PDT)
X-Received: by 2002:a25:b790:: with SMTP id n16mr1875277ybh.309.1615837074056;
 Mon, 15 Mar 2021 12:37:54 -0700 (PDT)
Path: eternal-september.org!reader02.eternal-september.org!news.mixmin.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Mon, 15 Mar 2021 12:37:53 -0700 (PDT)
In-Reply-To: <87im5sutdt.fsf@nightsong.com>
Injection-Info: google-groups.googlegroups.com; posting-host=146.5.2.231; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC
NNTP-Posting-Host: 146.5.2.231
References: <38356aa9-b8b0-4e0b-a490-99e7b239d0b1n@googlegroups.com>
 <cb298727-0c0b-454c-bf64-3f264096f899n@googlegroups.com> <87im5sutdt.fsf@nightsong.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <07812e30-8fe7-4ed4-ad30-3c94447af08fn@googlegroups.com>
Subject: Re: Ada and "early return" - opinion/practice question
From: Shark8 <onewingedshark@gmail.com>
Injection-Date: Mon, 15 Mar 2021 19:37:54 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Xref: reader02.eternal-september.org comp.lang.ada:61538
List-Id: <comp.lang.ada>

On Monday, March 15, 2021 at 1:08:48 PM UTC-6, Paul Rubin wrote:
> Shark8 writes:=20
> > Exceptions, typically. Sometimes a return itself, typically in a=20
> > procedure though.
> This is interesting: I thought in the Java and C++ worlds, using=20
> exceptions to manage normal control flow was frowned on, in part because=
=20
> the exception mechanism is quite heavyweight. And in Haskell,=20
> exceptions are considered i/o effects and therefore nasty in pure code=20
> (code with side effects is "impure" and has a special type signature).=20
>=20
> Is there wisdom about this in Ada?

In Ada there's a lot more flexibility and robustness thanks to the type-sys=
tem.
Take, for example, something like a password type:

Subtype Upper is Character range 'A'..'Z';
Subtype Lower is Character range 'a'..'z';
Subtype Special is Character
  with Static_Predicate =3D> '!'|'@'|'#'|'$'|'%'|'^'|'&'|'*'|'('|')' | '-'|=
'_'|'+'|'=3D';

-- a password is a string of length between 7 and 40 with a combination of =
upper-case, lower-case, and special characters, but at least one from each =
group.
Type Password is new String
  with Dynamic_Predicate =3D> Password'Length in 7..40
  and (for all C of Password =3D> C in Upper|Lower|Special)
  and (for some C in Password =3D> C in Upper)
  and (for some C in Password =3D> C in Lower)
  and (for some C in Password =3D> C in Special);

Now, given an object (constant, variable, parameter) of "X : Password" and =
subprogram Do_Something( Input : Password ) a compiler can omit checks on t=
he constraints* for Do_Something( Input =3D> X ), because the object's cons=
traints were already checked. Moreover, because the checking is attached to=
 the type/subtype, you can't forget** to check the validity of the subtype.=
 So having TYPE HANDLE IS NOT NULL ACCESS OBJET'CLASS; means that every sin=
gle parameter taking HANDLE, or return emitting HANDLE, has embedded into i=
t a check against the null value.



* Kind-of, it's a special case because there are no function-calls here whi=
ch can change the validity of a password. In the most general case, because=
 it's a Dynamic_Predicate attached to the Password-type, we can't _know_ th=
is is safe. (e.g. a validity-function that alters what's valid based on run=
time conditions.)
** There are some things that can get through because the predicate-system =
uses the same system as ASSERT does, so turning off assertions can break as=
sumptions.