Function call or variable? 
Author Message
 Function call or variable?

Given that the following lines are the only code in the
module, how can one determine if the identifier "func_or_var"
is a function call or variable?  Is it possible
to come any conclusion at all?  Assume that the identifier
"func_or_var" is defined in another module.

-- File starts here
with This_System;
use This_System;

procedure Validate(a, b : in out integer) is
begin
  if (func_or_var)
    a := b;
  end if;
end Validate;
-- End of file



Wed, 23 Aug 1995 07:31:21 GMT  
 Function call or variable?

Quote:

> how can one determine if the identifier "func_or_var"
> is a function call or variable?
>   if (func_or_var) [then]

you cant tell by looking at the reference, but have to look at the definition.
that is IMHO a _very_ good thing.

it means that the implementation can change between parameterless function and
constant and variable and client code need not be modified.
similarly, you can change between a function and an array without changing
client code.  the semantics are the same, just the implementation has changed.

this doesnt mean that you shouldnt care about how something is implemented, but
that you should only record that design decision in one place instead of
propogating the info throughout the code.

the same principle that makes private types so useful.

if not convinced, consider this scenario, you have a constant or variable referenced
throughout your code - and as time goes on, the code to keep it set
correctly gets more and more complex and needs to be invoked from more
and more places.  In Ada, you can replace the variable with a function safely.
Code that only references the variable need not change at all.
in C, you would have to modify every caller.

this syntactic ambiguity allows better information hiding of implementation details.
the compiler needs to know the details, but the caller doesnt.
overloading is another example of a useful apparent ambiguity,
which the compiler resolves based on complete information from the definition.

for this reason, I really object to coding styles which try to distinguish
syntactically those things that the language intentionally does not.
such as using a space or not before left parens to tell distinguish
function calls from array references.  thats a bad idea.

--
---------------------------------------------------



Fri, 25 Aug 1995 04:27:06 GMT  
 Function call or variable?
You can always assign _to_ the variable.  More importantly, you cannot
tell the difference between a function and a *constant*.  After all,
the semantics of enumeration literals (for instance) is that they are
parameterless functions that return a value of the enumeration type.
                                dave


Fri, 25 Aug 1995 08:34:42 GMT  
 Function call or variable?

Quote:


> (Thomas Huynh) writes:
> > how can one determine if the identifier "func_or_var"
> > is a function call or variable?
> >   if (func_or_var) [then]
> you cant tell by looking at the reference, but have to look at the
> definition.  that is IMHO a _very_ good thing.
> it means that the implementation can change between parameterless
> function and constant and variable and client code need not be
> modified.  similarly, you can change between a function and an array
> without changing client code.  the semantics are the same, just the
> implementation has changed.

The semantics aren't entirely the same---there are important
differences between constants and parameterless functions.  For
example, you can use a constant in a CASE selector, but not a
parameterless function.  There are other contexts in Ada where
constant expressions are required;  in this case, constant may appear
while parameterless functions may not.  The obvious difference between
variables, arrays, and function calls, is that you can put variables
and arrays on the left side of an assignment (or pass them as OUT or
IN OUT parameters).

Quote:
> this doesnt mean that you shouldnt care about how something is
> implemented, but that you should only record that design decision in
> one place instead of propogating the info throughout the code.
> the same principle that makes private types so useful.

I agree that private types are extremely useful.  The difference here
is that with private types, you can change the definition of the type
any way you want, but the type identifier's class doesn't
change---i.e., the type remains a TYPE---and the rest of the program
won't have to change at all.  Changing from a parameterless function
to and from a constant doesn't have this property---the identifier's
class changes and some of the semantics change with it.

If a package makes a constant value publicly available, but the program
designer anticipates that the program may change later such that the
value won't be a constant any more, I would strongly argue that the
value should be implemented as a parameterless function from the
beginning.  The function's body will be trivial if the value is a
constant, but when the program is modified later, only the function
body needs to be changed.  The package spec won't change at all, and
this is the best way to guarantee that the remainder of the program
will not have to change just because the implementation of this one
value changes.  There won't be any loss of efficiency if you use
PRAGMA INLINE (and your compiler supports it).  This, I think, is the
logical parallel to private types.

Quote:
> if not convinced, consider this scenario, you have a constant or
> variable referenced throughout your code - and as time goes on, the
> code to keep it set correctly gets more and more complex and needs
> to be invoked from more and more places.  In Ada, you can replace
> the variable with a function safely.  Code that only references the
> variable need not change at all.  in C, you would have to modify
> every caller.

Not necessarily.  You could use #define to ensure that the program is
changed in only one place.  I don't believe I've ever seen any C code
that's designed like this, though.

Quote:
> [other stuff deleted]

Alex has made some pretty good arguments why parameterless functions
and variables/constants should have the same syntax, and I'm sure
there are good arguments the other way too.  What's a little amusing
about this is that, in my opinion, none of these design arguments were
actually factors in how the language syntax was decided on.  I don't
have any evidence to back this up, but I'm willing to bet that
parameterless procedures are the way they are in Ada because they were
that way in Ada's ancestors, Pascal and Algol.  C's syntax was
probably designed to make it easy for the compiler's parser.

Back in the early 80's, when Ada was in the design process, I remember
reading an article by someone who pointed out the advantages of having
function calls and array references have the same syntax---both use
parentheses, while in other languages array references use square
brackets.  However, this clearly had nothing to do with the real
reason array references use parentheses; the real reason is that
EBCDIC doesn't have square brackets.  This made the article seem like
a lame, after-the-fact rationalization, even though it did make some
valid points.

                                -- Adam



Wed, 30 Aug 1995 08:39:49 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. indirect function calls and variable variables

2. indirect function calls and variable variables

3. Function call or variable?

4. VC++ calling fortran function and fortran function calling a c++ function

5. How to find out name of calling function from called function

6. calling function recursively, local variables?

7. Local variables, call-back functions under Windows

8. evaluating a variable as a function call?

9. calling a variable from a separate function

10. Call a function using a variable

11. How update variable values by calling secondary functions ?

12. variable function call

 

 
Powered by phpBB® Forum Software