In the interest of email sanity, please make sure that neither Larry's preferred : nor the more-common > are valid at statement start...
I'd hate to stumble across : -> - like 'sub' ; And run the risk of it compiling both as a quote and not. =Austin --- Larry Wall <[EMAIL PROTECTED]> wrote: > On Fri, 25 Oct 2002, Michael Lazzaro wrote: > : Since it's been a full month since the start of the monster > "operator > : precedence" thread, here's what I've been able to gather as the > : revised, new-and-improved list of Perl6 operators, IF we did all > the > : xor/cat/regex-related changes as discussed as of this moment. ;-) > I > : think this list is accurate and complete so far, LMK? > > Getting there. > > : $ - dereference scalarref > : @ - dereference arrayref > : % - dereference hashref > : & - dereference coderef > > These are not currently operators, just as they aren't really > operators > in Perl 5. If you say > > $( foo() ) > @( bar() ) > > you don't get a dereference as it currently stands. You'd have to > use > > ${ foo() } > @{ bar() } > > But maybe that's something we should talk about. > > : * - list flattening > : ? - force to bool context > : ! - force to bool context, negate > : + - force to numeric context > : - - force to numeric context, negate > : ~ - force to string context > > We're obviously missing the "force to string context, negate" > operator. :-) > > : -X - filetest operators > > Which are actually considered a variant of named unaries, if I > recall... > > : other postfix operators: > : > : [] - array access > : {} - hash access > > And () when an operator is expected rather than a term. > > : hyperoperators: > : > : ^ - as prefix to any unary/binary operator, "vectorizes" the > > : operator > > One is tempted to make it "v" instead of "^", but then we couldn't > have > any actual operators starting with "v". > > : binary operators: > : + - * / % ** x ~ << >> > : += -= *= /= %= **= x= ~= <<= >>= > > We could distinguish an xx operator (along with xx=) that does list > replication, rather than requiring parens around the left argument. > > : < > <= => == != <=> > : lt gt le ge eq ne cmp > > Er, that would be >=, not =>. > > : && || !! // - boolean operations > : &&= ||= !!= //= > : and or xor > : > : .& .| .! - bitwise operations > : .&= .|= .!= > > Now I'm wondering whether these should be split into: > > +& +| +! - bitwise operations on int > +&= +|= +!= > > ~& ~| ~! - bitwise operations on str > ~&= ~|= ~!= > > Except the . looks more like a bit. And the current str/int rules > don't > cause that much problem. One could perhaps force it this way: > > +$x .| +$y > ~$x .| ~$y > > And it's more like the semantics people are used to, for some > definition of "people", and some definition of "used to". I dunno... > > Maybe it's really > > .& .| .! - bitwise operations on int > .&= .|= .!= > > .and .or .xor - bitwise operations on str > .and= .or= .xor= > > except that "and", "or" and "xor" aren't string ops in real life... > > Could go with > > .a .o .x - bitwise operations on str > .a= .o= .x= > > Or we could leave .& et al. as the unmarked form, and just mark the > string-wise version, thus falling further into the Icon trap: > > .~& .~| .~! - bitwise operations on str > .~&= .~|= .~!= > > Then we could allow > > @a ^.~|= @b; # hyper bitwise string or-equals > > but only with a special rule in the grammar that makes the comment > mandatory. :-) > > : & | ! - superpositional > : all any one (none?) > > I think a good case can be made for *not* defining the corresponding > super assignment operators: &=, |=, and umm...I guess it would have > to be !=, er... > > : ~~ !~ - smartmatch and/or perl5 '=~' (?) > : like unlike > > Or something like/unlike that... > > : .= - (?) > > Not sure I believe in this one as method call because it confuses the > variable with the value. Besides, somebody's gonna expect it to mean > the same as .!($a .! $b), though that would be .== in fact, I > suppose. > > : -> - like 'sub' > > Not really an operator. But if you count this you also have to count > the optional "hash" on the front of "hash { foo() }", where it's not > clear whether the {} is a hash or a sub. > > : .. - range > : ... - yada**3 > > Mmm, not really. yada xx 3 is a term, not an operator. As an > operator, ... is likely to have the Ruby interpretation of omitting > the endpoint (unless we make it mean ..Inf or some such). > > : is > > Not really a general operator. Basically only availabe on > declarators. > > : parens, misc, and quotelike operators: > : > : () > > Plus [] and {} when a term is expected! > > : m// > : s/// - still around, but maybe shorthand for something > else > : tr/// > > Most special quote forms are likely to be shorthand for something > else... > > : '...' "..." `...` /.../ > : q qq qx qr qw > > I'd still love to the double angles for a qw synonym. > > : (heredocs) - (exact format unknown) > : > : > : named unary (prefix) operators: > : > : my our temp > > "my" and "our" aren't really operators. On the other hand, "temp" > is, and so is "let", which seems to be missing from your list. > > : not ref defined undef > : length exists delete > > "not" is not the same precedences as "named unary" operators. > "length" > is probably just a method of str, Array, etc. > === message truncated === __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/