actual for variable name must be variable compiler error

actual for variable name must be variable compiler error

[Stribor40]

I have procedure that define..

procedure myFunction (a: in out INTEGER) is
    begin


    end

which gets called in main like this....

   myFunction(5) this gives me error that actual must be variable
   myFunction(SomeOtherVariable) compiles fine

Can anyone please explain whats the difference. Should in out be allowed to read and write to parameters. 

Re: actual for variable name must be variable compiler error

[Jeffrey Carter]

On 09/28/2014 05:48 PM, Stribor40 wrote:
> 
> procedure myFunction (a: in out INTEGER) is

Do you also have a function Myprocedure?

>    myFunction(5) this gives me error that actual must be variable
>    myFunction(SomeOtherVariable) compiles fine

"in" means the subprogram reads the parameter; "out", that it assigns to the
parameter; and "in out" that it does both. You can only assign to a variable.
Certainly not to a numeric literal.

-- 
Jeff Carter
"I wave my private parts at your aunties."
Monty Python & the Holy Grail
13

Re: actual for variable name must be variable compiler error

[Brian Drummond]

On Sun, 28 Sep 2014 17:48:20 -0700, Stribor40 wrote:

> procedure myFunction (a: in out INTEGER) is
>     begin
        a := 4;
>     end;
 
>    myFunction(5) this gives me error that actual must be variable

is equivalent to
   
   5 := 4;

Not bloody likely!

- Brian

Re: actual for variable name must be variable compiler error

[Denis McMahon]

On Sun, 28 Sep 2014 17:48:20 -0700, Stribor40 wrote:

> Can anyone please explain whats the difference. Should in out be allowed
> to read and write to parameters.

You can't pass a literal value to a function parameter of type in out.

At the end of the procedure, it will write the updated value back to the 
calling statement. When it tries to do that, if you passed it a literal 
value, what is it going to send the updated value back to?

It can't change a literal 5 into a 4 or a 6 if the parameter was modified 
in the procedure, but you've told it (by declaring the parameter in out) 
that you want the parameter written back to the calling statement.

It's like writing:

5 = fn(5)

-- 
Denis McMahon, denismfmcmahon@gmail.com

Re: actual for variable name must be variable compiler error

[Simon Clubley]

On 2014-09-29, Brian Drummond <brian3@shapes.demon.co.uk> wrote:
> On Sun, 28 Sep 2014 17:48:20 -0700, Stribor40 wrote:
>
>> procedure myFunction (a: in out INTEGER) is
>>     begin
>         a := 4;
>>     end;
>  
>>    myFunction(5) this gives me error that actual must be variable
>
> is equivalent to
>    
>    5 := 4;
>
> Not bloody likely!
>
> - Brian

The problem may be that in C it's possible to write the following:

#include <stdio.h>

void update_value(unsigned long int a);

int main(int argc, char *argv[])
	{
	update_value(4);
	update_value(6);
	return(0);
	}

void update_value(unsigned long int a)
	{
	printf("Value of a on entry to update_value() is %lu\n", a);
	a = a + 7;
	printf("Value of a after modification is %lu\n", a);
	return;
	}

which when compiled and run gives:

[simon@[deleted] ~]$ gcc -Wall -Werror -o ro_update ro_update.c
[simon@[deleted] ~]$ ./ro_update 
Value of a on entry to update_value() is 4
Value of a after modification is 11
Value of a on entry to update_value() is 6
Value of a after modification is 13
[simon@[deleted] ~]$

Notice how you can modify (at least locally) what in Ada would be an
in parameter and it doesn't matter if an integer constant was passed
as was done in this case.

The OP may be getting confused and thinking you can do the same
with integer constants in Ada.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: actual for variable name must be variable compiler error

[Georg Bauhaus]

On 29.09.14 21:37, Simon Clubley wrote:
> void update_value(unsigned long int a)
> 	{
> 	printf("Value of a on entry to update_value() is %lu\n", a);
> 	a = a + 7;

Once you submit to contradictions like "a equals a + 7" being signs
of advanced understanding---though wondering how that could be---
you are well prepared for an introduction to more programming quizzes,
such as why and when `5' may become a name of 4.
  In fact, functionist's favorite REPL is sufficiently lenient,

Prelude> let 5 = 4 in 5
5

> 	printf("Value of a after modification is %lu\n", a);
> 	return;
> 	}

Re: actual for variable name must be variable compiler error

[Simon Clubley]

On 2014-09-29, Georg Bauhaus <bauhaus@futureapps.invalid> wrote:
> On 29.09.14 21:37, Simon Clubley wrote:
>> void update_value(unsigned long int a)
>> 	{
>> 	printf("Value of a on entry to update_value() is %lu\n", a);
>> 	a = a + 7;
>
> Once you submit to contradictions like "a equals a + 7" being signs
> of advanced understanding---though wondering how that could be---
> you are well prepared for an introduction to more programming quizzes,
> such as why and when `5' may become a name of 4.

The only time I've ever done anything like that was back in my student
days with an old (even at the time) Fortran IV compiler which passed
everything, including integer constants, by reference and the constants
were shared between program statements in a literal pool. There was also
no read-only memory protection within a process on this miniframe.

One day I passed an integer constant (4, IIRC) into a subroutine.
I'll let you work out what happened next. However, it taught me one hell
of a lesson which I've never forgotten. :-)

To return to the issue at hand, I posted the example without comment
instead of the rant about the "wonders" of C I was feeling while
creating it.

However, I want to make it clear I don't write production code like
that. If an in parameter needs modifying in a C program it gets copied
into a local variable and worked on there. Modifying an in parameter
in the way it's done in my example just feels so very wrong to me even
when the language lets you do it...

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: actual for variable name must be variable compiler error

[Peter Chapin]

On 2014-09-29 20:27, Simon Clubley wrote:

> However, I want to make it clear I don't write production code like
> that. If an in parameter needs modifying in a C program it gets copied
> into a local variable and worked on there. Modifying an in parameter
> in the way it's done in my example just feels so very wrong to me even
> when the language lets you do it...

In C parameters have the same status as local variables. If it is
convenient to modify it, then I modify it just as I might modify a
local. If it is not something to be modified one can declare it const as
with any local

void f(const int x)
{
    x = 5;   // Error. Modifying a const.
}

I use a tool (PC-Lint) that can be configured to remind me whenever a
parameter could be declared const. I generally try to follow its advice
in this area.

Peter

Re: actual for variable name must be variable compiler error

[Dennis Lee Bieber]

On Tue, 30 Sep 2014 00:27:54 +0000 (UTC), Simon Clubley
<clubley@remove_me.eisner.decus.org-Earth.UFP> declaimed the following:

>However, I want to make it clear I don't write production code like
>that. If an in parameter needs modifying in a C program it gets copied
>into a local variable and worked on there. Modifying an in parameter
>in the way it's done in my example just feels so very wrong to me even
>when the language lets you do it...
>
	The main concept is that the parameter, in C, is effectively already a
local copy... Changes don't propagate back out (unless one has explicitly
declared it a pointer type and is doing dereferencing on the pointer; or a
C++ reference parameter).

	In FORTRAN, it was always a reference and the compiler handled
dereferencing for you.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: actual for variable name must be variable compiler error

[Adam Beneschan]

On Monday, September 29, 2014 5:27:56 PM UTC-7, Simon Clubley wrote:

> However, I want to make it clear I don't write production code like
> that. If an in parameter needs modifying in a C program it gets copied
> into a local variable and worked on there. Modifying an in parameter
> in the way it's done in my example just feels so very wrong to me even
> when the language lets you do it...

It's definitely caused problems for me, in Pascal, which also lets you do that.  There have been lots of times where I've seen the header of a procedure/function with its parameters and with documentation that describes the parameters, and then I look toward the end of the procedure/function and see a use of the parameter, and assume it's the value that got passed in--only to find out later during testing that the "local copy" got changed earlier.  Often I've found that I needed to make a change in that part of the code and I really needed the original value, but it wasn't stored anywhere.  To be honest, though, this has mostly been a problem with procedures/functions that were far too long to begin with.  I suppose that modifying an "in" parameter might be OK in a very short function, shorter than 10 lines.  But longer than that, and I think you risk causing the same kind of confusion I've had problems with (of course, you should consider breaking it down anyway).

                                    -- Adam

Re: actual for variable name must be variable compiler error

[Simon Clubley]

On 2014-09-30, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:
> On Tue, 30 Sep 2014 00:27:54 +0000 (UTC), Simon Clubley
><clubley@remove_me.eisner.decus.org-Earth.UFP> declaimed the following:
>
>>However, I want to make it clear I don't write production code like
>>that. If an in parameter needs modifying in a C program it gets copied
>>into a local variable and worked on there. Modifying an in parameter
>>in the way it's done in my example just feels so very wrong to me even
>>when the language lets you do it...
>>
> 	The main concept is that the parameter, in C, is effectively already a
> local copy... Changes don't propagate back out (unless one has explicitly
> declared it a pointer type and is doing dereferencing on the pointer; or a
> C++ reference parameter).
>

Yes, I know, but visually it looks really weird in the code especially
when you use other languages such as Ada in which such a parameter is
immutable or other languages in which such a change would be pushed
back to the caller (and trigger a trying to change a literal type error
in this case).

Adam also makes a really good point and there's a good element of that
potential for confusion in the code in my objections as well.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world