Re: Precedence table update
On Sat, Aug 14, 2004 at 08:57:21AM -0700, Larry Wall wrote: : You'll also want to make sure the zip operator (¥) gets in there, : probably with the same precedence as == (unless we decide it's : a scalar-only operator, in which case it can be tighter because it : would only work on array refs). It also has self-associativity issues : much like ^ and == and, if you squint, semicolon inside subscripts. It the moment the zipper has moved to be the same precedence as comma, because it really wants to be looser than ranges but tighter than listops. Plus it's sort of like a »,« if you squint. I'm eagerly awaiting my first opportunity to use the »¥« operator in anger... Larry
Re: Precedence table update
Larry Wall skribis 2004-08-18 15:37 (-0700): It the moment the zipper has moved to be the same precedence as comma, because it really wants to be looser than ranges but tighter than listops. Plus it's sort of like a »,« if you squint. I'm eagerly awaiting my first opportunity to use the »¥« operator in anger... Which makes me wonder: is there another core-only set of operators that renders as ???, or can we safely assume that ??? is Y (I still don't see why infix:Y would be wrong, and want it badly, because prefix zip() doesn't quite feel the same)? Let's see... ?foo bar baz?# qw %foo?bar?# qw @foo ?+? @bar# hyper @foo ? @bar # zip I guess it's not as bad as I initially thought. Even when rendered badly, I think in most cases it will still be recognisable. (Hm, can the real ? be made intelligent enough to dwim? Then I can even *copy and paste* the new operators in this terminal and have it dwym.) Juerd
Re: Precedence table update
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.
2) Did the boolean logics (?, ?|. ?^ and their assignment forms) get
dropped?
3) Am I right in assuming the file tests (-x, -r, etc...) are
considered named unaries?
4) Am I right in assuming ^.. , ..^ and ^..^ are open ended versions of
.. ?
5) Did ... get dropped?
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.)
7) The operator .+foo is listed twice on the method postfix line. Did
a real operator accidentally get missed?
8) What is .«» ?
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?
- Mark
Mark Lentczner
http://www.ozonehouse.com/mark/
[EMAIL PROTECTED]
Re: Precedence table update
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
Re: Precedence table update
On Aug 14, 2004, at 12:17 AM, Larry Wall wrote: Here's the current precedence table as I see it, based mostly on what the, er, cabal came up with after the Perl conference. Okay, time to get out the quill and parchment and start work on revising the Periodic Table of the Operators - Mark hope the tallow candle lasts 'till dawn Lentczner Mark Lentczner http://www.ozonehouse.com/mark/ [EMAIL PROTECTED]
Re: Precedence table update
On Sat, Aug 14, 2004 at 08:42:51AM -0700, Mark Lentczner wrote: : : On Aug 14, 2004, at 12:17 AM, Larry Wall wrote: : Here's the current precedence table as I see it, based mostly : on what the, er, cabal came up with after the Perl conference. : : Okay, time to get out the quill and parchment and start work on : revising the Periodic Table of the Operators : : - Mark hope the tallow candle lasts 'till dawn Lentczner You'll also want to make sure the zip operator (¥) gets in there, probably with the same precedence as == (unless we decide it's a scalar-only operator, in which case it can be tighter because it would only work on array refs). It also has self-associativity issues much like ^ and == and, if you squint, semicolon inside subscripts. Larry
