in reply to Re: explanation of constant syntax? ()
in thread explanation of constant syntax?

... except people don't tend to think of constants as "function calls". That's what they are, in Perl, but it's not, er, part of their job description.
  • Comment on Re^2: explanation of constant syntax? ()

Replies are listed 'Best First'.
Re^3: explanation of constant syntax? (clear)
by tye (Sage) on Mar 20, 2004 at 18:46 UTC

    Yep, constants aren't very clear in Perl... unless you write them like FOO(). It clears up what is really going on to the user.

    It also clears up what is going on to Perl. Barewords are quite ambiguous in Perl. Is it a function call, a string, a reserved word, a file handle, a package name, ... ? Sometimes Perl is forced to guess and sometimes guesses wrong (just like in the original node). So I almost always add the trailing parens to make things clear to man and beast.

    One exception is that I sometimes call subroutines that take arguments without the parens to get compile-time notice when I mispel the routine name. But I only do that for statements (never in the middle of an expression), because there are even more ambiguities to trip on.

    - tye        

      I'm not sure that's necessarily helpful. The value of constant subs gets inlined at compile time, so while they share the syntax of function calls they do not share their semantics. There is no function call, even though it looks like one to the reader.

      Makeshifts last the longest.

        Yes, FOO() is clearer than FOO or (FOO). The latter two could be strings or file handles or perhaps other things.

        Yes, you can't tell whether FOO() is a constant function and so whether FOO() gets called at compile time or at run time. But neither FOO nor (FOO) make that any clearer, either.

        Earlier today you wrote

        my $tmp = io;

        and io() isn't a constant, so you don't appear to reserve bareword usage for constants. So, how can the more ambiguous syntax be anything but less clear?

        You know that the function doesn't get called at run time for constants. But that is an implementation detail and an optimization and so isn't particularly important. It doesn't change the function of the program and not knowing about it isn't going to trip you up when you try to understand what the code is doing.

        I've certainly never been in a situation where I've slapped my forehead and said "Of course! That's why it isn't behaving right. I didn't (notice|put in) (the lack of|) the empty prototype!".

        - tye