Re: Function call or variable?

[adam@irvine.com (Adam Beneschan)]

In article <64872@mimsy.umd.edu> alex@cs.umd.edu (Alex Blakemore) writes:

> In article <9303051531.aa21226@Paris.ics.uci.edu> lhuynh@siam.ICS.UCI.EDU 
> (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).

> 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.

> 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.

> [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