in reply to sub STDERR { *STDERR } -- nearly works !

I guess this works as expected:
print {STDERR} "+++STDERR: '", STDERR, "'\n" ;

Replies are listed 'Best First'.
Re^2: sub STDERR { *STDERR } -- nearly works !
by gone2015 (Deacon) on Apr 09, 2008 at 09:52 UTC

    Not sure I'd bracket 'works as expected' and Perl together :-)

    For completeness, it's being parsed as:

      print STDERR("+++STDERR: '", ....) ; -- predeclared sub STDERR without a prototype.

      print STDERR() "+++STDERR: '", .... ; -- predeclared sub STDERR ()

    where the second is treated as a broken expression involving the return value of STDERR().

    This behaviour is consistent with the general handling of subroutines referenced by a bareword.

    Where a FILEHANDLE may appear the parser has to jump through hoops to allow print $FH ...., which it parses as a FILEHANDLE and leaves as a run-time problem. With an ordinary print FH .... the parser also leaves checking that FH actually refers to something to run-time.

    Having predeclared sub FH () { *FH } ; I can see that the parser is in a bit of a bind when it sees print FH "Hi!";. The prototype says that FH("Hi!") is not the correct interpretation. But it does know that FH is a sub..., even though, on the face of it, it looks just like a filehandle !

    I imagine that generalising print FH .... even further, so that the FH could be an expression that returned a filehandle object, would be a nightmare -- leaving broken code to be found at run-time. However, the special case of a predeclared subroutine with a () prototype might be a small step ?

    The other thing that is special about filehandles is that there is no way to declare them. Suppose one could declare our FH : filehandle ; (say). Now: (a) strict could throw out print SPELING_ERROR ...; and (b) use of FH in an expression could return *FH{IO} implicitly, so some_sub(FH, ....) or $object->{handle} = FH would work just fine ! Of course, STDERR et al could then be predeclared with a 'filehandle' attribute :-)