It is not very often that ignoring a function result is okay, but I have run across many instances of the following block structure in code over the years:

declare
dont_care : BOOLEAN;
begin
dont_care := foo( x, y );
end;

I also see the procedure wrapper used in some cases -- usually when exported in a package specification:

procedure FOO( x, y ) is
b : BOOLEAN;
begin
b := foo( x, y );
end FOO;

The procedure adds nothing to the code except another thing to maintain when the function interface needs modification.

Is there a Ada 202x feature to support calling functions and ignoring the result? If not, I'm wondering if the @ symbol recently introduced for assignments could be used? How would people feel about the following?

@ := foo( x, y );

This would discard the result of the function. This could obviously lead to memory leaks (without reference counting), but the syntax could be restricted for use on functions that do not return uncontrolled access types or these functions could be marked with a keyword to make it legal for it to be called in such a way when the programmer knows that the access returned should not be "freed" by the caller (such as a pointer into an existing structure).

I have not given this much thought so I'm sure there are reasons why this can't (or shouldn't) be done in general. Regardless, there are probably many that would agree with me that the declare block and the wrapper procedure options are annoying and could be considered superfluous for lack of a better way to write the code more simply.

Matt

On 6/29/21 9:25 PM, Matt Borchers wrote:
> It is not very often that ignoring a function result is okay, but I have run across many instances of the following block structure in code over the years:
>
> declare
> dont_care : BOOLEAN;
> begin
> dont_care := foo( x, y );
> end;

This sort of thing usually indicates a design problem.

> Is there a Ada 202x feature to support calling functions and ignoring the result?
If you want to use a language that allows this, then you probably shouldn't be
developing S/W.

--
Jeff Carter
"Blessed is just about anyone with a vested interest in the status quo."
Monty Python's Life of Brian
73

On 2021-06-29 21:52, Jeffrey R. Carter wrote:
> On 6/29/21 9:25 PM, Matt Borchers wrote:
>> It is not very often that ignoring a function result is okay, but I
>> have run across many instances of the following block structure in
>> code over the years:
>>
>> declare
>>      dont_care : BOOLEAN;
>> begin
>>      dont_care := foo( x, y );
>> end;
>
> This sort of thing usually indicates a design problem.

True. But there are exceptions from the rule:

1. Bindings to other languages. You normally have the result and you
quite often ignore it because it is useless.

2. Side effects of the call. Normally you would overload a function with
a procedure, like here:

function Pop (Stack : not null access Stack_Type) return Element;
procedure Pop (Stack : in out Stack_Type);

But you will have a problem (which BTW the proposal fail to address)
when overloading is solely on the result:

function Get (File : File_Type) return Integer;
function Get (File : File_Type) return Float;
function Get (File : File_Type) return String;

Now if you wanted to skip an integer in the file you could not do it in
the proposed way:

@ := Get (Standard_Input); -- Ambiguous

@ := Integer'(Get (Standard_Input)); -- Ugly

And of course, as many times proposed before a better syntax would be
the null statement:

null <expression>; -- Does not address the problem either

>> Is there a Ada 202x feature to support calling functions and ignoring
>> the result?
> If you want to use a language that allows this, then you probably
> shouldn't be developing S/W.

I would not say that pieces like:

declare
Ignore : constant Bar := Foo (Baz);
begin
null;
end;

or

if Foo (X) then null; end if;

are good engineering. But excessive overloading may lead to unexpected
collisions if you have many parameters with defaults.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:sbg04v$i7i$1@gioia.aioe.org...
....
> Now if you wanted to skip an integer in the file you could not do it in
> the proposed way:
>
> @ := Get (Standard_Input); -- Ambiguous
>
> @ := Integer'(Get (Standard_Input)); -- Ugly

Maybe you think qualification is "ugly", but it is precisely the Ada tool
for this sort of problem. It wouldn't make sense to invent a new mechanism
when an existing one does the job just fine (and it's hard to imagine a
disambiguation mechanism that didn't include the subtype name).

> I would not say that pieces like:
>
> declare
> Ignore : constant Bar := Foo (Baz);
> begin
> null;
> end;

In Ada 202x, renaming is easier (assuming the usual case where overloading
isn't involved):

declare
Ignore renames Foo (Baz);
begin
null;
end;

BTW, I disagree with the OP's premise. To me, this sort of thing is
*exactly* what you need to do, since it makes it clear that you are ignoring
the result. And that typically is hidden inside of a thicker binding, so
it's pretty rare (it won't happen in well-designed Ada packages, but as
Dmitry says, it will often happen in interfacing, at least with the
Microsoft stuff!).

....

> But excessive overloading may lead to unexpected collisions if you have
> many parameters with defaults.

Excessive overloading is obviously bad, so the above doesn't say much. :-)
Determining when overloading is excessive is the hard part. Recent
experience suggests that a lot of overloading is ultimately execessive (the
need to change the name of some containers procedures demonstrates this!!)

Randy.

On 29/06/2021 20:52, Jeffrey R. Carter wrote:

>> declare
>>      dont_care : BOOLEAN;
>> begin
>>      dont_care := foo( x, y );
>> end;
>
> This sort of thing usually indicates a design problem.

Or interfacing with C.

>
>> Is there a Ada 202x feature to support calling functions and ignoring
>> the result?
> If you want to use a language that allows this, then you probably
> shouldn't be developing S/W.
>

That's literally every C programmer then.

On 29/06/2021 20:25, Matt Borchers wrote:
> It is not very often that ignoring a function result is okay, but I have run across many instances of the following block structure in code over the years:
>
> declare
> dont_care : BOOLEAN;
> begin
> dont_care := foo( x, y );
> end;

declare
Dont_Care : constant Boolean := foo (x, y); -- Uppercase is so pascal!
pragma Unused (Dont_Care); -- GNAT specific
begin
null;
end;

I would put into a procedure, especially if it's a binding to C.

"Luke A. Guest" <laguest@archeia.com> writes:

> declare
> Dont_Care : constant Boolean := foo (x, y); -- Uppercase is so pascal!
> pragma Unused (Dont_Care); -- GNAT specific
> begin
> null;
> end;

There are several names that you don't need pragma Unreferenced (not
Unused) for - see
https://docs.adacore.com/live/wave/gnat_rm/html/gnat_rm/gnat_rm/implementation_defined_pragmas.html#pragma-unreferenced

"For the variable case, warnings are never given for unreferenced
variables whose name contains one of the substrings DISCARD, DUMMY,
IGNORE, JUNK, UNUSED in any casing. Such names are typically to be
used in cases where such warnings are expected. Thus it is never
necessary to use pragma Unreferenced for such variables, though it is
harmless to do so."

On 30/6/21 8:26 pm, Luke A. Guest wrote:
>
> declare
>    Dont_Care : constant Boolean := foo (x, y); -- Uppercase is so pascal!
>    pragma Unused (Dont_Care); -- GNAT specific
> begin
>    null;
> end;
>

or even ...

declare
Dont_Care : constant Boolean := Foo (X, Y) with Unreferenced;
begin
null;
end;

Matt Borchers <mattborchers@gmail.com> writes:

> It is not very often that ignoring a function result is okay, but I
> have run across many instances of the following block structure in
> code over the years:
>
> declare
> dont_care : BOOLEAN;
> begin
> dont_care := foo( x, y );
> end;

With, GNAT, this can be:

declare
dont_care : BOOLEAN := foo( x, y );
pragma Unreferenced (dont_care);
begin
null;
end;

which makes the intent clear. I don't know if Unreferenced was proposed
as a language addition; it's not in Ada 202x.

--
-- Stephe

"Stephen Leake" <stephen_leake@stephe-leake.org> wrote in message
news:867diayk1o.fsf@stephe-leake.org...
....
> declare
> dont_care : BOOLEAN := foo( x, y );
> pragma Unreferenced (dont_care);
> begin
> null;
> end;
>
> which makes the intent clear. I don't know if Unreferenced was proposed
> as a language addition; it's not in Ada 202x.

Unreferenced controls warnings, which (with one exception) are not an Ada
concept. So how would we describe what it does? Aspect unreferenced does
nothing at all?? :-)

One could imagine an aspect that caused a Legality Rule against an actual
reference, but I don't think that is what the GNAT aspect does.

Randy.

On Tuesday, June 29, 2021 at 9:52:40 PM UTC+2, Jeffrey R. Carter wrote:
> On 6/29/21 9:25 PM, Matt Borchers wrote:
> > It is not very often that ignoring a function result is okay, but I have run across many instances of the following block structure in code over the years:
> >
> > declare
> > dont_care : BOOLEAN;
> > begin
> > dont_care := foo( x, y );
> > end;
> This sort of thing usually indicates a design problem.
> > Is there a Ada 202x feature to support calling functions and ignoring the result?
> If you want to use a language that allows this, then you probably shouldn't be
> developing S/W.
>
> --
> Jeff Carter
> "Blessed is just about anyone with a vested interest in the status quo."
> Monty Python's Life of Brian
> 73

Yes, you are right.
But sometimes it is necessary (especially at the H/W level) to force a read of
a peripheral register in order to obtain a specific behaviour, e.g., clear an interrupt
or latch a value previously written; in these cases what you read is useless.
G

On Thursday, 1 July 2021 at 19:07:43 UTC+1, Gabriele Galeotti wrote:
> But sometimes it is necessary...

Yes, but the frequency is too low to justify yet another feature of the language, IMO.

On 6/29/2021 2:25 PM, Matt Borchers wrote:
> It is not very often that ignoring a function result is okay, but I have run across many instances of the following block structure in code over the years:
>
> declare
> dont_care : BOOLEAN;
> begin
> dont_care := foo( x, y );
> end;
>
> I also see the procedure wrapper used in some cases -- usually when exported in a package specification:
>
> procedure FOO( x, y ) is
> b : BOOLEAN;
> begin
> b := foo( x, y );
> end FOO;
>

fyi, Matlab had this for years:

https://www.mathworks.com/help/matlab/matlab_prog/ignore-function-outputs.html

"
This example shows how to ignore specific outputs from a function using the tilde (~) operator.
To ignore function outputs in any position in the argument list, use the tilde operator. For example, ignore the first output using a tilde.

[~,name,ext] = fileparts(helpFile);

"

--Nasser

Thanks for the feedback. I guess I have to live with five lines to accomplish what one should do regardless of the numerous variety of ways to accomplish this. I mostly appreciate the wordiness of Ada for the clarity it offers to the code maintainers, but in some cases the extra wordiness offers nothing.

Related to this, I really appreciate the new parenthesized expressions as it offers a clean way to declare simple functions. GNAT 21.2 was just released today and includes declare expressions. I don't have the compiler yet, but I wonder if this would work:

procedure FOO( x, y ) is (declare b : BOOLEAN := foo( x, y ));

but it seems likely that an expression returns a value and would not be allowed in this instance.

Le samedi 3 juillet 2021 à 06:59:19 UTC+2, Matt Borchers a écrit :
> Thanks for the feedback. I guess I have to live with five lines to accomplish what one should do regardless of the numerous variety of ways to accomplish this. I mostly appreciate the wordiness of Ada for the clarity it offers to the code maintainers, but in some cases the extra wordiness offers nothing.

If you use functions properly (only "in" parameters and not side effects) you don't have this issue at all.
Interfacing with C is an edge case which doesn't need to add more noise in the Ada syntax, IMHO.

*no* side effects

> [~,name,ext] = fileparts(helpFile);

In Ada it would be:
Info := File_Parts (Help_File);

You would use Info.name and Info.ext informations in the record only and ignore the other field.
Not much more complicated...

On 2021-07-03 10:37, Gautier write-only address wrote:
> Le samedi 3 juillet 2021 à 06:59:19 UTC+2, Matt Borchers a écrit :
>> Thanks for the feedback. I guess I have to live with five lines to
>> accomplish what one should do regardless of the numerous variety of
>> ways to accomplish this. I mostly appreciate the wordiness of Ada
>> for the clarity it offers to the code maintainers, but in some
>> cases the extra wordiness offers nothing.
>
> If you use functions properly (only "in" parameters and not side
> effects) you don't have this issue at all.

However, the problem then changes to ignoring unneeded "out" parameters
of procedures, and the only way (currently) is to declare dummy output
variables and then leave them unused.

But it is not a big problem, and not worth changing the language, IMO.

> Interfacing with C is an edge case which doesn't need to add more
> noise in the Ada syntax, IMHO.

I agree.

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Stephen Leake" <stephen_leake@stephe-leake.org> wrote in message
> news:867diayk1o.fsf@stephe-leake.org...
> ...
>> declare
>> dont_care : BOOLEAN := foo( x, y );
>> pragma Unreferenced (dont_care);
>> begin
>> null;
>> end;
>>
>> which makes the intent clear. I don't know if Unreferenced was proposed
>> as a language addition; it's not in Ada 202x.
>
> Unreferenced controls warnings, which (with one exception) are not an Ada
> concept.

This could be another exception, or we could make it an Ada concept.

> So how would we describe what it does? Aspect unreferenced does
> nothing at all?? :-)
>
> One could imagine an aspect that caused a Legality Rule against an actual
> reference, but I don't think that is what the GNAT aspect does.

It does give you a warning if the variable is referenced.

--
-- Stephe

On Friday, July 2, 2021 at 9:32:24 AM UTC+2, amado...@gmail.com wrote:
> On Thursday, 1 July 2021 at 19:07:43 UTC+1, Gabriele Galeotti wrote:
> > But sometimes it is necessary...
>
> Yes, but the frequency is too low to justify yet another feature of the language, IMO.

Well, I agree it's ok to keep a rigid language semantics. The price to pay is then
accept some kind of warning (that add noise), or write the offending code
in an ad-hoc machine language fragment (which add further noise).
To be honest, I see this kind of feature as a "normal" pragma to the underlying
optimizer/linker/etc. Unfortunately, the H/W world is often far from perfect.

On Friday, July 2, 2021 at 9:32:24 AM UTC+2, amado...@gmail.com wrote:
> On Thursday, 1 July 2021 at 19:07:43 UTC+1, Gabriele Galeotti wrote:
> > But sometimes it is necessary...
>
> Yes, but the frequency is too low to justify yet another feature of the language, IMO.

Note: in the last reply, I am referring to the use of pragma Unreferenced, not a new language feature.

G

Gabriele Galeotti <gabriele.galeotti.xyz@gmail.com> writes:

> On Friday, July 2, 2021 at 9:32:24 AM UTC+2, amado...@gmail.com wrote:
>> On Thursday, 1 July 2021 at 19:07:43 UTC+1, Gabriele Galeotti wrote:
>> > But sometimes it is necessary...
>>
>> Yes, but the frequency is too low to justify yet another feature of
>> the language, IMO.
>
> Note: in the last reply, I am referring to the use of pragma
> Unreferenced, not a new language feature.

or aspect Unreferenced, or if you're prepared to accept GNAT extensions
anyway, just call the not-referenced variable Dummy, or Unused, or .. I
listed the relevant variable names upthread.

I suspect you _won't_ get a warning if you do reference a variable named
Dummy, but at that point it should be pretty obvious that something's
wrong.

I think any compiler needs some facility like this, at least if it has
any pretensions to interfacing to foreign languages; but it probably
won't be the same as Ada's.

Simon Wright <simon@pushface.org> writes:

> I think any compiler needs some facility like this, at least if it has
> any pretensions to interfacing to foreign languages; but it probably
> won't be the same as Ada's.

.... the same as *GNAT*'s.

Sorry, people

"Simon Wright" <simon@pushface.org> wrote in message
news:lya6n32oxi.fsf@pushface.org...
....
> I think any compiler needs some facility like this, at least if it has
> any pretensions to interfacing to foreign languages; but it probably
> won't be the same as Ada's.

Perhaps "any compiler that tries to warn about unused objects". Janus/Ada
doesn't do that, so it doesn't need some facility to turn it off, either.
But I grant that if it did have such a warning, then some method to turn it
off is needed. (We have a pragma Warning_Level for turning off classes of
warnings in selective areas, nothing for individual warnings -- my
assumption has been that a warning message mught change when the compiler
gets upgraded, but the class of warning will not [unless of course there is
something else wrong].)

Randy.

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?
Too many of those omissions have invited, uhm, a number of things.

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.