On 2021-07-09 21:14, G.B. wrote:
> On 30.06.21 08:06, Randy Brukardt wrote:
>
>> In Ada 202x, renaming is easier (assuming the usual case where
>> overloading
>> isn't involved):
>>
>>     declare
>>        Ignore renames Foo (Baz);
>>     begin
>>        null;
>>     end;
>
> Is this "type-less" naming a copy of the popular omission schemes
> like auto in C++? Optional type annotations in Swift, or Scala?

I don't know all the origins of this language change, but it can be seen
as a correction because it avoids the wart in the earlier Ada form of
renaming, where a (sub)type name is included. The wart is that the
constraints of that (sub)type are essentially ignored, and so can be
misleading.

AI12-0275 seems to be the main origin of this change:

http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai12s/ai12-0275-1.txt?rev=1.9&raw=N

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message
news:ikrlspFjskkU1@mid.individual.net...
....
>> Is this "type-less" naming a copy of the popular omission schemes
>> like auto in C++? Optional type annotations in Swift, or Scala?
>
>
> I don't know all the origins of this language change, but it can be seen
> as a correction because it avoids the wart in the earlier Ada form of
> renaming, where a (sub)type name is included. The wart is that the
> constraints of that (sub)type are essentially ignored, and so can be
> misleading.

Right; the name of the type is often a lie vis-a-vis the subtype properties;
moreover, it is often the case that the type is included in the renamed
item:

Foo : renames Some_Type'(Bar(Obj));

Repeating the type in such cases is not useful and violates DRY ("Do Not
Repeat Yourself"):

Foo : Some_Type renames Some_Type'(Bar(Obj));

We felt this was something that was better handled by style guides rather
than imposing unnecessarily wordy syntax.

> AI12-0275 seems to be the main origin of this change:
>
> http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai12s/ai12-0275-1.txt?rev=1.9&raw=N

The actual motivation behind this change was a strong desire for a shorter
way to write bindings in declare expressions. We tried a number of things,
but they all seemed oddly special case. Eventually, we settled on using
normal syntax throughout declare expressions, but simplified the syntax for
renaming in all cases. The tipping point was noticing the duplication in
examples like the above, along with the fact that the subtype given is
ignored anyway.

If we were designing Ada from scratch, the subtype in a renames would have
to statically match the nominal subtype of the name being renamed. But that
wasn't required in Ada 83 and it would be way too incompatible to require
now. (The reason that Ada 83 didn't require it? Jean Ichbiah didn't want to
have to define "static matching" -- according to an old thread that John
Goodenough dug up. Of course the Ada 9x team decided such a concept was
necessary and added it to the language, so we ended up with most constructs
using static matching, but renames being different.)

Randy.

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;
> also good for implementors of more complex type inference algorithms
> and, consequently, for makers of the CPUs that are needed to properly
> handle the omissions. I think the proper number of omissions is
> a subject of research at ETH Zürich. They are trying to find
> a sweet spot that makes inference finish in reasonable time.
I tend to dislike type-inference* almost altogether; I think Ada 2012 and before 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 general] a static portion of the program as a whole it should be possible (to borrow from the GPS UI) to throw up the little wrench/auto-fix option and "fill 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 inference again and again and again on each compile and waste your time.

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