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/
