On Sun, Aug 15, 2004 at 02:12:53PM -0700, Mark Lentczner wrote:
: I apologize if the answers to these questions are in the list
: somewhere, but I can't find any archive of this list that lets me
: search for things like ^..^ or ?&= !
:
: In reviewing the operator precedence table update, I have some
: questions:
:
: 1) What is unary ** ? I assume it is prefix.
Yes, it's the really-really-flatten-this-list-right-now splat. That is,
apply Perl 5 semantics to the list. It can be used in the declaration
of the slurp array as well.
: 2) Did the boolean logics (?&, ?|. ?^ and their assignment forms) get
: dropped?
No, just didn't happen to get mentioned--the lists were meant to be
representative, but some of them started looking rather exhaustive.
: 3) Am I right in assuming the file tests (-x, -r, etc...) are
: considered named unaries?
Yes.
: 4) Am I right in assuming ^.. , ..^ and ^..^ are open ended versions of
: .. ?
Yes. The ^ is meant to be mnemonic meaning "exclusive" of the endpoint.
: 5) Did ... get dropped?
Nope, I just didn't want to confuse people with calling it a binary operator.
It has the same precedence as .. does, but doesn't look for a following
argument. Alternately, the third dot *is* the argument. :-)
: 6) What is the precedence of postfix () , {} and [] ? They surely are
: tighter than the list ops:
: print @foo[4], @bar[$i];
: The [4] doesn't close the virtual parenthesis of print, so [] must be
: tighter than that. Is the whole construct @foo[4] considered a term
: and hence the postfix [] is even tighter than every operator listed?
: (Though I would consider it a postfix operator.)
Those are just dot postfix operators where the "dot" is silent... :-)
But you're right in a sense, in that all the dot postfix operators
could be considered just part of the preceding term. It just that with
a dot, there can be intervening whitespace and comments. For those
bracketing constructs that can omit the dot, you have to omit the
whitepace as well.
: 7) The operator .+foo is listed twice on the method postfix line. Did
: a real operator accidentally get missed?
Yes, there's supposed to be a .:foo to call a private method.
: 8) What is .«» ?
Same as .{qw//}, including ability to slice a hash with multiple
whitespace-separated subscripts, and ability to drop the dot if
you juxtapose it.
: 9) What is "{} as control block" mean? As if after a for or if? Does
: this really count as an operator? Similarly, the statement modifiers
: are in the same boat. Does these things act as operators or are then
: in the realm of the recursive descent grammar?
They're in the realm of things that have to recognized by the operator
precedence grammar as terminating and bombing back out to recursive
descent. That's all. It's sort of cheating to put them in with
semicolon, since semicolon within brackets can continue in operator
precedence, with more slices of a multi-dimensional array subscript.
But that could also be in the realm of recursive descent. In fact, any
of this operator stuff *could* be done with recursive descent--we just
choose not to dive down through 22+ levels of recursion on every term.
(22+ because the user can define more precedence levels on the fly.)
Larry
