On Thu, Jan 15, 2009 at 10:52:55PM -0800, Mark Lentczner wrote:
> I'm re-working my "Periodic Table of the Operators" chart to be up-to-
> date. I did the first major pass based on S03-operators. However, the
> last few days I've been plowing through STD.pm and have discovered that
> there some differences. Since STD.pm is considered more up to date, I'll
> be changing the chart to match that. However, I thought it would be
> useful to share the detailed list of differences I found. Besides, there
> are some embedded questions in there, I'd love to have answered.
>
> Thanks,
> - Mark
>
>
> STD.pm: r24855 | lwall | 2009-01-10
> S03-operators.pod r24895 | lwall | 2009-01-13
>
> == Associativity ==
>
> Prefix and postfix precedence levels have no associativity in STD, but
> are left (mostly) or right in S03. Levels affected are:
> %methodcall
> %autoincrement
> %symbolic_unary
> %named_unary
> %loose_unary
> %list_prefix
Fixed, but it took a while. :)
> Some levels have left associativity in STD, but are list in S03. Levels
> affected:
> %concatenation
> %tight_and
> %tight_or
> %loose_and
> %loose_or
Fixed.
> Oddly, sym<^^> ( --> Tight_or) is forced to :assoc<list> in STD.
It is now naturally list.
> ?? Even though for most of these operators there is no computational
> difference between left and list assoc, list seems more "in the spirit"
> to me. I plan on leaving them listed as 'list' assoc in the chart unless
> there is a reason to make them left.
List is correct. And, in fact, list associativity now devolves to right
associativity rather than left.
> Conditional level is right in STD, and left in S03.
Is right.
> == Added ==
>
> STD has a new Methodcall operator construction:
> token privop ( --> Methodcall) {
> '!' <methodop>
> }
> ?? What is this?
Private method call, described in S12.
> STD has postfix:sym<i>. I understand this is the imaginary operator.
Yes.
> STD has infix:sym<.=>. I understand this to be the method call
> assigning form when there is space after the operator.
> ?? Is this right?
Putting no space before and a space after may be a syntax error.
We have a postfix form, and an infix form, but mixing the two
will look to the parser like an incomplete postfix. Then again,
it might backtrack and find it currently. It's arguable whether
"progress" has been made in a predictive parser sense.
> STD has <==, ==>, <<==, and ==>> as true operators. S03 groups them as
> terminators.
Fixed S03.
> STD has sym<;> as both an infix operator ( --> Sequencer), and as a
> terminator.
> ?? Which is it? Since I think most people think of it as a statement
> terminator, I plan on leaving it off the chart.
STD now parses it consistently as a statement terminator (or as a
special delimiter in argument lists, but that's more or less the same).
> STD is missing sym<\\> at Symbolic_unary level.
> ?? Did capture cease to be an operator?
It's a special form, primarily to distinguish it from "unspace", but
also to discourage its application to temporary results without use
of full \(...) capture notation. Or to look at it another way, it's
an operator at "term" precedence. :)
> STD is missing sym<mod> at Multiplicative level.
> ?? I'm assuming this is just an oversight.
Indeed.
> == Misc ==
>
> The ff and fff family are at %nonchaining precedence in STD, but at
> %conditional precedence in S03.
Conditional, since they involve thunks, and the right associativity
doesn't really hurt them (or help them). More practically, it lets
you use && and || in the conditionals.
> STD has infix:sym<andthen> and infix:sym<orelse> each declared as tokens
> twice. I'm assuming this is just some accidental duplication.
Yes.
> At Loose_unary, STD has <colonpair> which seems more general than the
> operator adverbs discussed in S03 at Loose unary precedence.
The cutoff is actually at "epsilon tighter than comma", which allows
for user-defined precedence levels in between.
> The infix:sym<:> invocant marker is at Comma precedence in STD, but List
> prefix in S03. It is also left assoc. in STD, but right in S03.
It is at comma precedence, which is list assoc. Since we switched to
right associative degeneracy
meth $x: 1,2,3
and since : and , are at the same level, it now groups as:
meth ($x : (1,2,3))
rather than the old
meth (($x : 1), 2, 3)
which I only discovered a couple days ago, and was greatly astonished. :)
An alternative would be to establish a category of list assoc operators
that pay no attention to changing operators. That might also allow us
to treat p5=> as exactly identical to comma. Basically we'd have
operators lying about their sym, which implies that they'd have to
store a "reallysym" somewhere to have any semantic effect downstream.
Still thinking about the ramifications of that, and whether there's
some more general idea I'm missing.
> The sigils used as operators at List_prefix in STD include sym<&>. It
> isn't listed in S03.
> ?? Should it be included as an operator, or is it senseless as an
> operator?
Operator, for consistency if nothing else.
> S03 lists the a number of named listops:
> all one any none die warn fail item list slice hash
> These aren't coded expressly in STD, presumably as they are all handled
> by the generic named listop code.
> ?? Is there any reason to call them out in a list of operators as S03
> does? Or is it just that these named listops happen to be the same as
> existing symbolic ones and are worth pointing out.
They're merely examples.
> The named listops seem to be handled in STD by
> token term:identifier ( --> Term )
> But this is at Term precendence, not List_prefix.
> ?? Did these move?
This is how listops have always been in Perl, term precedence on the
left and listop precedence on the right. Rather like $ in Haskell.
> The ! metaop in STD requires that the op be either chaining or have an
> associativity (any) and be :bool. But %chaining is the only set of
> operators that has :bool...
> ?? Is this just "belt and suspenders" checking, or can that meta op
> apply to more?
The intent is that if the user defines a new precedence level, it
may have :bool set, and the corresponding metaops will be autogenerated.
Arguably it should not depend on a :bool flag but on the actual return
type of the operator. (Also arguably, there should be a - metoperator
to apply to anything returning the Order type, such as cmp, leg, and <=>.)
But we don't really have a way of declaring that yet, so we probably
need to at least generalize :bool into :returns(Bool) or some such.
Larry
