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-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=3.0 tests=BAYES_20,FREEMAIL_FROM
	autolearn=ham autolearn_force=no version=3.4.6
X-Received: by 2002:a37:6044:: with SMTP id u65mr22882901qkb.330.1626105415515;
        Mon, 12 Jul 2021 08:56:55 -0700 (PDT)
X-Received: by 2002:a25:690e:: with SMTP id e14mr65749146ybc.277.1626105415362;
 Mon, 12 Jul 2021 08:56:55 -0700 (PDT)
Path: eternal-september.org!reader02.eternal-september.org!weretis.net!feeder8.news.weretis.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, 12 Jul 2021 08:56:55 -0700 (PDT)
In-Reply-To: <sca3lg$de5$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=146.5.2.231; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC
NNTP-Posting-Host: 146.5.2.231
References: <69a59fdc-72bb-4202-99fc-d776530de653n@googlegroups.com>
 <sbftm5$1gn$1@dont-email.me> <sbg04v$i7i$1@gioia.aioe.org>
 <sbh1lf$i1c$1@franka.jacob-sparre.dk> <sca3lg$de5$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <632d76a4-bac0-4052-8f99-76eb3e5e0072n@googlegroups.com>
Subject: Re: calling function but ignoring results
From: Shark8 <onewingedshark@gmail.com>
Injection-Date: Mon, 12 Jul 2021 15:56:55 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Xref: reader02.eternal-september.org comp.lang.ada:62374
List-Id: <comp.lang.ada>

On Friday, July 9, 2021 at 12:14:10 PM UTC-6, G.B. wrote:
> They'll be good, for sure, when securing the workplace semantically;=20
> also good for implementors of more complex type inference algorithms=20
> and, consequently, for makers of the CPUs that are needed to properly=20
> handle the omissions. I think the proper number of omissions is=20
> a subject of research at ETH Z=C3=BCrich. They are trying to find=20
> a sweet spot that makes inference finish in reasonable time.
I tend to dislike type-inference* almost altogether; I think Ada 2012 and b=
efore got it right: very constrained and deterministic contexts (eg the for=
 loop's index).
Yes, I realize there's systems like Haskell that are good about types, but =
as you say these have inferences that take a while. While I'm all in favor =
of making the compiler do the tedious work, given that types are [in genera=
l] a static portion of the program as a whole it should be possible (to bor=
row from the GPS UI) to throw up the little wrench/auto-fix option and "fil=
l in" the types found so that the next compile doesn't have to infer types.=
.. but I suspect that most implementations will instead simply do the infer=
ence again and again and again on each compile and waste your time.

* It invites the "could possibly work" C-ish mentality, rather than the "ca=
nnot possibly not-work" Ada-mentality, IMO.