From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	ip-172-31-91-241.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=3.0 tests=FREEMAIL_FROM autolearn=ham
	autolearn_force=no version=3.4.6
X-Received: by 2002:a05:622a:1a1d:b0:417:fcf8:905c with SMTP id f29-20020a05622a1a1d00b00417fcf8905cmr57131qtb.10.1696015392779;
        Fri, 29 Sep 2023 12:23:12 -0700 (PDT)
X-Received: by 2002:a05:6870:5b9c:b0:1e1:40df:f0d1 with SMTP id
 em28-20020a0568705b9c00b001e140dff0d1mr826601oab.11.1696015392391; Fri, 29
 Sep 2023 12:23:12 -0700 (PDT)
Path: eternal-september.org!news.eternal-september.org!border-1.nntp.ord.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Fri, 29 Sep 2023 12:23:11 -0700 (PDT)
In-Reply-To: <u5rjg8$1dr0c$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=76.113.94.233; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC
NNTP-Posting-Host: 76.113.94.233
References: <u5rjg8$1dr0c$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <c5c09218-e170-4c16-b793-024683f21568n@googlegroups.com>
Subject: Re: does a safer language mean it is slower to run?
From: Shark8 <onewingedshark@gmail.com>
Injection-Date: Fri, 29 Sep 2023 19:23:12 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Xref: news.eternal-september.org comp.lang.ada:65753
List-Id: <comp.lang.ada>

On Wednesday, June 7, 2023 at 9:55:55=E2=80=AFPM UTC-6, Nasser M. Abbasi wr=
ote:
> Some folks in this thread=20
>=20
> https://discourse.julialang.org/t/comparison-of-rust-to-julia-for-scienti=
fic-computing/78508=20
>=20
> "I=E2=80=99m not an expert, but my feeling is that Rust is a =E2=80=9Csaf=
er=E2=80=9D language,=20
> which to me means it must be slower."=20
>=20
> etc..=20
>=20
> Some in that thread seem to argue that a safer language=20
> will/could be slower than otherwise.=20
>=20
> Since Ada is known to be one of the safest languages,=20
> do others here feel there is any truth to this?=20
>=20
> I thought that by having more type information in the language,=20
> the compile will be able to make more optimizations (because it=20
> know more), and hence the generated code should actually be=20
> faster, not slower with a language that is less safe?=20
>=20
> I am not a compiler expert but what do others here think?=20
>=20
> --Nasser

An interesting proposition fueled by two differing intuitions: one, saying =
that mandatory checks must necessarily slow things down, and the other sayi=
ng that having more information allows for greater optimization.

We can, of course, walk through a few simple/trivial examples to flesh out =
which intuition is more correct.

FIRST, let's consider Array-access in Ada, which mandates a check on the in=
dex:

Subtype Real is Float range Float'Range; -- Removing NaN, INF, etc.
Type Real_Vector is array (Positive range <>) of Real;
Function Normalize(Input : in Real_Vector) return Real_Vector is

   Function Maximum return Real is
   Begin
      -- Start w/ Negative-most number; geturn the maximum.
      Return Result : Real:=3D Real'First do
         For Index in Input'Range loop
            Result:=3D Real'Max(Result, Input(Index));
         end loop;
      End return;
   End Maximum;
  =20
Begin
   case Input'Length is
      when 0 =3D> Return Input;
      when 1 =3D> Return (1 =3D> 1.0);
      when others =3D>
         Return Result : Real_Vector(Input'Range) do
            declare
               Max : Real renames Maximum;
            begin
               For Index in Result'Range loop
                  Result(Index):=3D Input(Index) / Max;
               End loop;
            end;
         End return;
   end case;
End Normalize;

In the above, we see the control of the For-loop, "Index", which takes its =
values from the input (directly or indirectly), and therefore the indexing =
of Input(Index) *cannot* be outside the bounds of the array, Input. This me=
ans that we can omit the checks altogether as Index is bound to the constra=
ints of the array. And we can deduce this directly from the source, at comp=
ile-time, therefore allowing us to remove the checks altogether.

SECOND, consider:

Type Window is tagged private;
Type Window_Pointer is access all Window'Class;
Subtype Window_Handle is not null Window_Pointer;

Procedure Set_Title( Object : Window_Handle; Text : String );

In the above, we see that Object is an access to Window'Class which exclude=
s Null -- since this constraint is enforced to the parameter on-call, in th=
e body the compiler can assume that "Object /=3D Null" is true.

THIRD, similar to the second:

Type Safe_Text is String
   with Dynamic_Predicate =3D> (for all Ch of Safe_Text =3D> Ch in 'a'..'z'=
|'A'..'Z'|' '||'0'..'9');
Function Transform( Input : Safe_Text ) return Safe_Text;

X : Safe_Text :=3D Transform(Transform(Transform(Transform( Whatever ))));

in the above, we note that the parameter is checked for conformance, raisin=
g exception CONSTRAINT_ERROR if it fails, and is guaranteed to either retur=
n a Safe_Text value or else raise an exception -- applying these, we can el=
iminate all the checks for the parameter except the innermost, thus optimiz=
ing in a way that you cannot if your input and output types were more broad=
.

So, the intuition that "more information provides more optimization opportu=
nity" is the correct one.