From mboxrd@z Thu Jan  1 00:00:00 1970
Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Ichbiah 2022 compiler mode
Date: Sat, 21 Dec 2024 02:19:09 -0600
Organization: A noiseless patient Spider
Message-ID: <vk5tlv$3uq1o$1@dont-email.me>
References: <vbc625$at65$1@dont-email.me> <vbdgs7$hedr$1@dont-email.me> <vk53gs$3lfp0$2@dont-email.me>
Injection-Date: Sat, 21 Dec 2024 09:19:11 +0100 (CET)
Injection-Info: dont-email.me; posting-host="a539143aaaf8e240cfd1c441013bf73f";
	logging-data="4155448"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/QdDyAr1N2WeWadax5A0W49puj7UOsEv4="
Cancel-Lock: sha1:MTkSZib4YIPINh+6b/7Wrjf6YRQ=
X-MSMail-Priority: Normal
X-RFC2646: Format=Flowed; Response
X-Priority: 3
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246
Xref: news.eternal-september.org comp.lang.ada:66497
List-Id: <comp.lang.ada>

"Lioneldraghi" <lionel.draghi@free.fr> wrote in message 
news:vk53gs$3lfp0$2@dont-email.me...
> Le 06/09/2024 à 02:03, Randy Brukardt a écrit :
>
>> (10) Variable-returning functions are introduced. They're pretty similar 
>> the
>> semantics of anonymous access returns (or the aliased function returns
>> suggested by Tucker). This means that a variable can easily be treated as 
>> a
>> function (and indeed, a variable declaration is just syntactic sugar for
>> such a function).
>
> I suppose that to allows the compiler to discriminate this non sense code
> > Square (2) := 3;
>
> from the legitimate
> > List.Index (3) := Item;
>
> you will have to introduce some specific syntax, like Tucker's "aliased 
> function".
>
> I see the huge benefit from a user point of view, but I'm not aware of 
> compiler internals : doesn't the introduction of a second function type 
> increase complexity?

Yes, but Ada already has a bunch of different mechanisms for dealing with 
objects/functions/exceptions/packages/types. My intent is to collapse those 
all into one (somewhat more complex) mechanism. The basic idea is that 
everything resolves a single way, meaning that everything can be overloaded, 
and there no longer is a semantic difference between:
     A : constant T := ...;
and
     function A return T is (...);

Whether that really helps remains to be seen, of course. But the goal is to 
reduce the number of disjoint mechanisms both in the language description 
and in the implementation. The hope is then to be able to introduce 
additional capabilities on top of a simpler and stronger foundation.

                   Randy.