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
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
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
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 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
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
Larry Wall writes:
> Also of note is that we decided to keep the relative precedence of
> assignment and comma the same as in Perl 5. It's just good
> documentation to parenthesize your lists when assigning,
Fair enough; documentation is good.
> ... and it prevents nasty surprises when C programmers write things
> like:
>
> loop $i = 0, $j = 0; $i < 10; $i++, $j += 10 {...}
But I'm less convinced by that reason -- surely we shouldn't be making
it easy for C programmers to write things lie that?
To put it another way round, I've not yet encountered somebody learning
Perl using loops like the above, but I've often seen them omit the
parens in list assignment; this seems like the wrong optimization to me.
Possibly it would suffice to have a better warning. (Yes, I know that
use diagnostics explains what's up, but few beginners seem to discover
diagnostics by themselves, and the actual warning is often puzzling.)
> Anyway, feel free to point out any infelicities we might not have
> considered.
It looks good to me!
Smylers
Precedence table update
Here's the current precedence table as I see it, based mostly
on what the, er, cabal came up with after the Perl conference.
[Cabal members: note that I've demoted cmp and <=> from chaining
relationals, and I've moved the pipe operators closer together.
I've also generalized the two middle categories to chaining and
non-chaining binaries, and stuffed "but" into the non-chaining,
since we neglected to deal with it.]
terms 42 "eek" $x /abc/ (1+2) a(1) :by(2) .meth listop(left)
method postfix .foo .+foo .?foo .*foo .+foo .() .[] .{} .«» .=foo
autoincrement ++ --
exponentiation **
symbolic unary ! + - ~ ? * ** +^ ~^ ?^ \
multiplicative * / % x xx +& +<< +>> ~& ~<< ~>>
additive+ - ~ +| +^ ~| ~^
junctive and (all) &
junctive or (any) | ^
named unary rand sleep abs etc.
nonchaining binary => but does cmp <=> .. ^.. ..^ ^..^
chaining binary != == < <= > >= ~~ !~ eq ne lt le gt ge =:=
tight and &&
tight or|| ^^ //
ternary ?? ::
assignment = := ::= += **= xx= etc. (but not .=)
list item separator ,
list op (rightward) <== print push any all true not etc.
pipe forward==>
loose and and
loose oror xor err
expr separator ; {} as control block, statement modifiers
Some random comments:
Hyper ops always have the same precedence as their unhyper versions.
List operators are terms on their left side only, just as in Perl 5.
Basically you can think of them kind of as an opening paren without a
corresponding closing paren. (Instead they're closed by something
of looser precedence.)
The .meth as a term is the one we call "unary dot" because it doesn't
have an invocant. But really it's just parsed as a term, because you
only get it when a term is expected. The method postfixes are when
an operator is expected. Dot itself is not really an operator--it
just introduces a postfix operator. This is important to understand
because, as a postfix operator, you only hyperize the left of it:
@foo».bar
All the bitwise operators are considered to be doing boolean algebra,
where 1 * 1 == 1, so they're just classified with the ordinary multiply
and divide operations. The bitwise shifts are also multiplicative,
but because they multiply or divide by two. The cabal felt the various
bit operators weren't important enough to warrant separate precedence
levels anymore. Even in C, people almost always parenthesize them
because they're not sure...
However, even though they've merged with the arithmetic operators,
you'll note that by the rules of boolean algebra, the "ands" are still
one precedence level tighter than the "ors". That is consistent
across all the "ands" and "ors" of every time. (And the corresponding
"not" is always tighter than either the "and" or the "or".)
The xx operator is in there with the x operator only for mnemonic
purposes. By rights it should probably be a lot looser if we want
it to "multiply lists", but we'll just force people to parenthesize
their lists, as we do with list assignment.
Junctions deserve their own levels because they're actually
constructing compound data values out of simple ones, so they need
to be looser than the simple data operators but tighter than the
comparison operators. Arguably they could be looser than named
unaries, but it sort of feels right to keep all the generic unary
and binary operators in the middle together.
There is no binary "nor" operator...
The generic non-chaining binaries are mostly the sorts of operators
that construct new objects (ranges, pairs, mixins) out of two related
values. Though admittedly, the numbers -1, 0, and 1 are a bit of a
stretch to think of that way in the case of cmp and <=>. I don't
think there's much merit in defining a "comparison result object"
that just happens to return -1, 0, or 1...
We haven't said much about associativity here. Mostly it's what you'd
expect. ** and = are right associative, ++/-- are nonassociative.
I think the main reason for lumping all the non-chaining binaries
together is that we should call them non-associative, and you have
to parenthesize to be clear whether you mean:
($a => $b) => $c
($a .. $b) .. $c
($a but $b) but $c
or
$a => ($b => $c)
$a .. ($b .. $c)
$a but ($b but $c)
Assuming those mean anything at all. Certainly a pair can contain
a pair as either its key or its value (or both).
Nothing much surprising down to the list ops. We decided to make
C and C list ops just to save a level of precedence,
though we'll probably actually make them able to process lists of
values so you can say weird things like
if all true $a, $b, $c {...}
and
if all not $a, $b, $c {...}
though admittedly
if not all $a, $b, $c {...}
reads a little better, and also presumably works. Or how about this?
if not all true $a, $b, $c {...
