Re: Perl6 Operator List
On Fri, 25 Oct 2002, Chris Dutton wrote: : So many operators... : : It's now clear what we need. Unicode operators. That should buy us at : least another week to hash out the rest of the necessary operators. ;-) : : It'd also silence the legions of critics who complain about Perl being : too easy to read if we, for instance, used the Kanji character for : watashi in place of $self, and the character(s) for anata for the : default topic. Er, yeah. And one of the overriding design goals of Perl 6 is that programs spend more time undefining operators than defining them. :-) Unfortunately, anata doesn't work for the default topic. The whole point of the default topic in Japanese is that it's the 0-pronoun. So it'd have to be referenced as the null string if we went that route. Come to think of it, that's precisely what's happening with .method(). But anata means "you", and you're generally the topic only if I say "anata wa", semantically speaking. You can also be the topic in a pragmatic sense if I'm asking you a question. But most topics are third person, not second. We'd have to use something like "kore" or "sore" if we wanted something for an explicit topic reference. But usually it's implicit in Japanese. In fact, in Japanese, that last sentence wouldn't have an "it": "But in Japanese is usually implicit." Or in Japanese word order, "But Japanese-in usually implicit-is." In any event, there isn't really a third person pronoun meaning "it". "that" is about as close as you get. Larry
Re: Perl6 Operator List
So many operators... It's now clear what we need. Unicode operators. That should buy us at least another week to hash out the rest of the necessary operators. ;-) It'd also silence the legions of critics who complain about Perl being too easy to read if we, for instance, used the Kanji character for watashi in place of $self, and the character(s) for anata for the default topic.
Re: Perl6 Operator List
On Fri, 25 Oct 2002, Michael Lazzaro wrote:
: What's the Official Perl difference between a named unary op and a
: one-arg universal method?
I didn't give the other half of the answer. A method is a term,
not an operator. It's the . in front of it that's the operator...
It's just that, in indirect-object syntax, the colon on
length $object:
is optional, so it looks a lot like unary operator. But I think
the precedence is probably LISTOP, not UNIOP, at least if we
stick with the Perl 5 approach of any listop grabbing all the
available args to the right. I don't see a good way to keep
the precedence of length and friends at UNIOP--at least, not
without having universal subroutines that just pass their
single arguments off to the object as a real method. The
question is whether there's any way to keep Perl 5's
print length $a, "\n";
so it still parses as expected. It seems a bit silly to have to
declare a universal sub like
sub *length ($x) { $x.length() }
On the other hand, we would like to make methods obey the same
argument parsing rules as subs. Which means that the above behavior
could be implied for untyped objects via
class Object {
method length ($x) {...}
}
without having to declare a universal sub. But that depends on our
assumption that any method call's syntax can be determined by looking
at the type of its left side. That has ramifications if the declared
type of the left side is a base class and we really want to call a
method in a derived class that exceeds the contract of the base class.
We can probably defer some of these decisions till run time, such
as whether to interpret an @foo argument in scalar or list context.
But changing the precedence of length from a LISTOP to a UNIOP can't
be deferred that way. Which is why we either need the parser to know
the uniop declaration of
sub *length ($x) { $x.length() }
or we have to make
print length $a, "\n";
illegal, and require people to say one of:
print length($a), "\n";
print (length $a), "\n";
print $a.length, "\n";
if there's a following list. The latter approach seems quite a bit
cleaner, in that it doesn't require either the parser or the programmer
to maintain special knowledge about a unary function called "length".
I think we also need to fix this:
print (length $a), "\n";
The problem with Perl 5's rule, "If it looks like a function, it *is*
a function", is that the above doesn't actually look like a function
to most people. I'm thinking we need a rule that says you can't put
a space before a dereferencing (...), just as you can't with {...}
or [...]. If you want to, then, as with {...} or [...] you have to
use .(...) instead. That is,
print .(length $a), "\n";
means
print(length $a), "\n";
but
print (length $a), "\n";
means
print( (length $a), "\n" );
If we ever allow a syntax like C++'s foo for who knows what
purpose, then it would have to follow the same rules, since it would
otherwise be ambigous with a < operator. So maybe we should start
telling people not to say things like $a<$b when they mean $a < $b.
One could argue that this rule should be followed for all bracketing
syntax, including Unicode. That would be consistent, at least. The
real name of subscripts is then always with the dot:
operator:.[]# subscript []
operator:.{}# subscript {}
operator:.()# subscript () aka function args
operator:.<># subscript <> (reserved)
...
operator:[] # array composer
operator:{} # hash or closure
operator:() # regular parens
operator:<> # an op that screws up <, <<, <=, and <=> :-)
...
That's assuming that matched brackets are always recognized and assumed to
have an expression in the middle.
Actually, it's not clear that operator:<> would mess up binary <
and friends. It looks as if those four are really:
term:[] # array composer
term:{} # hash or closure
term:() # regular parens
term:<> # the input symbol AKA call the iterator
...
So we note that we can actually get away with having all of:
operator:.<>
operator:<
term:<>
without ambiguity (assuming a consistent space rule). However,
if we ever had
operator:{
we couldn't do the trick of assuming an implicit operator before a
block in
if $a eq $b {...}
But now note how we could have all three of
$a++# operator:.++
$a ++ $b# operator:++
++$b# term:++
by applying the rule to non-bracketing characters as well. Basically,
operator:.op vs operator:op allows us to distinguish postfix ops from
binary ops, if we want. That might be cool.
But we have a problem if we want to specify a binary operator that begins
with dot. So it probably has to be:
postfix:++
infix:++
prefix:++
or some such. That still leaves us with a problem if they
Re: Perl6 Operator List
On Fri, 25 Oct 2002, Michael Lazzaro wrote:
: What's the Official Perl difference between a named unary op and a
: one-arg universal method?
The Perl 5 definition of named unary op is an operator with the
precedence of UNIOP in perly.c.
: E.g. why are "temp" and "let" both ops but
: "my, our, hash" are not?
Well, "temp" and "let" both have their primary function at run time.
"my" and "our" are declarative, so their primary function is at
compile time, though either can function as an lvalue at run time.
So while things like "my" might parse at the same precedence level
as a UNIOP, they're somewhat disqualified by not really being an
operator in the usual sense. Of course, you can always think of
them as operators that just happen to run immediately at compile time
'cuz they're too impatient to wait for run time. But they also tend
to require special syntax following them, such as "is", that isn't
allowed in the case of general
"hash {...}" can be considered an operator if "sub {...}" is.
But again, its primary function is to clarify the declarative intent
of the following braces, even though the braces do have a run-time
meaning. Ordinarily though, the braces are disambiguated by whether
there is => at the top level.
: (I also missed 'err', not sure on that one either.)
Yes, that should be there too.
Larry
Re: Perl6 Operator List
Brent Dax wrote:
Larry Wall:
# We're obviously missing the "force to string context, negate"
# operator. :-)
Which would create a superposition of all strings besides the given one,
right? (Oh crap, I think I gave Damian an idea... :^) )
The C<~none> operator covers that quite nicely:
$not_foo = ~none('foo');
...
if $str eq $not_foo {
print "Not 'foo'\n"
}
H. Maybe C is starting to grow on me. Bwah-ha-ha-ha-hah! >;-)
Damian
RE: Perl6 Operator List
Larry Wall:
# We're obviously missing the "force to string context, negate"
# operator. :-)
Which would create a superposition of all strings besides the given one,
right? (Oh crap, I think I gave Damian an idea... :^) )
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Re: Perl6 Operator List
On Fri, Oct 25, 2002 at 06:28:28PM -0400, Miko O'Sullivan wrote: > From: "Larry Wall" <[EMAIL PROTECTED]> > > : ? - 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. > :-) > > Mr. Wall, may I be excused? My brain is full. Oh, I have to stick it out > with everyone else? OK, um > > Just so I understand... why do we need "force to blah context" operators at > all? Are we planning on doing a lot of context forcing? Isn't "a lot of > context forcing" mean that the context concept isn't working? Nay, say I. I > think context will continue to work. Which means... maybe we don't need all > that shorthand. I've been quite happy with the scalar function in Perl5. > What if we just had a few more functions like that for the occasional > context forcing, or even just one "context" function that takes a context > name as the first argument. The negate operators we have already: perl -e '$x = "0"; print !$x' perl -e '$x = "10.000"; print -$x' The others save use doing: perl -e '$x = "2"; print !!$x' perl -e '$x = "10.000"; print -(-$x)' perl -e 'print "" . localtime' OK, Perl 5 doesn't have all these contexts, and these may be not the most compelling of examples, but you get the idea. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Perl6 Operator List, Take 2
Excellent (and valuble) work Michael. Thank-you. My turn for a few comments: & | ! - superpositional all any one (none?) Although there certainly are good uses for a C superpositional: push @list, $newval if $newval eq none(@list); print "In range\n" if 1 > none(@values) > 10; they can always be achieved with C instead: push @list, $newval if $newval ne all(@list); print "In range\n" if 1 < all(@values) < 10; Then there's the problem of finding a suitable infix operator. Overall, I think adding a C might be multiplying entities unnecessarily. ~~ !~ - smartmatch and/or perl5 '=~' (?) like unlike- (tentative names) Do we *really* need the alphabetic synonyms here? Me no like! ; - "lesser comma", list-of-lists creator Actually, I'd describe this as "greater" comma. Sure, it has lower precedence, but that means its scope of effect is greater. Maybe we need another name entirely for it. "Sequence separator" perhaps? ... - (maybe range exclusive of endpoint, or maybe ..Inf) I'd much prefer the latter. But note that that semantics changes it from an binary to a postfix unary operator. trinary operators: Nit pick: s/s// '...' "..." `...` /.../ << >> q qq qx qr qw s/qr/rx/ but - [op?]val properties Yes, it's an operator. Damian
Perl6 Operator List, Take 2
Here's try #2. Things that are not true operators or have other
caveats are marked, where known. LMKA.
unary (prefix) operators:
\ - reference to
* - list flattening
? - force to bool context
! - force to bool context, negate
not - force to bool context, negate
+ - force to numeric context
- - force to numeric context, negate
~ - force to string context
. - method call on current topic
++ - preincrement
-- - predecrement
unary (postfix) operators:
++ - postincrement
-- - postdecrement
other postfix operators:
() - [when operator is expected]
[] - array access
{} - hash access
hyperoperators:
^ - as prefix to any unary/binary operator, "vectorizes" the
operator
binary operators:
+ -*/%** xxx ~
+= -= *= /= %= **= x= xx= ~=
<><= >= == != <=>
lt gt le ge eq ne cmp
&&||!!//- boolean operations
&&= ||= !!= //=
and orxor err
.&.|.!<< >> - bitwise operations
.&= .|= .!= <<= >>= - (or is that .<<, .>>, etc?)
& | ! - superpositional
all any one (none?)
~~ !~ - smartmatch and/or perl5 '=~' (?)
like unlike- (tentative names)
=> - pair creator
, - list creator
; - "lesser comma", list-of-lists creator
: - adverbial
. - method call
.. - range
... - (maybe range exclusive of endpoint, or maybe ..Inf)
= - assignment
:= - binding
::= - binding, but more so
trinary operators:
?? ::
parens, misc, and quotelike operators:
()
[] - [when term is expected]
{} - [when term is expected]
m// - shorthand for something else
s/// - shorthand for something else
tr///- shorthand for something else
'...' "..." `...` /.../ << >>
q qq qx qr qw
(heredocs) - [exact format unknown]
named unary (prefix) operators, terms, and other assorted hangers-on,
identified when possible:
-X - [op] filetest operators
temp- [op]
let - [op]
ref - [op]
defined - [op]
undef - [op]
undef - [term]
exists - [op]
delete - [op]
${ }- [deref] dereference scalarref
@{ }- [deref] dereference arrayref
%{ }- [deref] dereference hashref
&{ }- [deref] dereference coderef
... - [term] yada**3
Inf - [term]
NaN - [term]
is - [declar] var properties
but - [op?]val properties
-> - [declar] like 'sub'
hash- [declar] force hash context
methods and listops, uncategorized:
my our
map grep
sqrtlogsin cos tan
lc lcfirstuc ucfirst
int ordoct hex (bin?)
MikeL
Re: Perl6 Operator List
From: "Larry Wall" <[EMAIL PROTECTED]> > : ? - 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. :-) Mr. Wall, may I be excused? My brain is full. Oh, I have to stick it out with everyone else? OK, um Just so I understand... why do we need "force to blah context" operators at all? Are we planning on doing a lot of context forcing? Isn't "a lot of context forcing" mean that the context concept isn't working? Nay, say I. I think context will continue to work. Which means... maybe we don't need all that shorthand. I've been quite happy with the scalar function in Perl5. What if we just had a few more functions like that for the occasional context forcing, or even just one "context" function that takes a context name as the first argument. -Miko uh oh, I just forced myself into numeric context and negated myself
Re: Perl6 Operator List
On Fri, Oct 25, 2002 at 01:00:59PM -0700, Larry Wall wrote: > On Fri, 25 Oct 2002, Michael Lazzaro wrote: > : 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. I initially thought that ^x would be a good way of expressing this, but now I'm not so sure. A hyper operator does some sort of vector version of an operator based on the dimensionality of the left argument. But for x vs xx the left argument has no change in dimensionality, and even swapping things round doesn't help, as the replication count is scalar. Nicholas Clark -- INTERCAL better than perl? http://www.perl.org/advocacy/spoofathon/
Re: Perl6 Operator List
On Friday, October 25, 2002, at 02:38 PM, Austin Hastings wrote: In the manner of Accent, I'd like @ reserved as the RPC operator. The Role Playing Character operator? Hmm, that has possibilities. What would this statement do? +--+ |..@...| |d.| |..| +--+ MikeL
Re: Perl6 Operator List
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
> 'kay. As an aside, I've always itched for a qlike op that was
> matrix-like, e.g.
>
> my Pet @list = qm{
> fido dog collie
> fluffy cat siamese
> };
That should be qo, and possibly @qo or qoo -- it quotes an object.
Since c knows what type thing $lunch is, there's no
reason not to either automagically invoke a constructor or list of
init-funcs for $lunch, or at least create a temporary anonymous Pet and
then copy/clone it.
Likewise, either @lunch implies that qo takes multiple (perhaps a
single object can simply init with { attr, attr, ... }) or qoo does
arrays...
my Pet @dogs = qo{ # Note {} delims looks more like collars ...
fidodogcollie
fluffy catsiamese
};
> And I always wished
>
> $=
> @=
> %=
Isn't % the modulus (remainder-after-division) operator? And isn't %=
the perform-and-assign version thereof?
---
In the manner of Accent, I'd like @ reserved as the RPC operator.
(There aren't many Accent programmers, but I am one of them, and it's a
[barely] living language used in a production environment. I'm not
proud of this, mind you ... :-)
$result = myfunc($arg, $arg2) @ $host;
This implies that @= is a pretty useless op, but maybe if tasks are
objects it's not so bad.
my Task dostuff = qo( myfunc 0 ); # function, priority
$dostuff @= $otherhost;
$dostuff.start;
This is admittedly a stretch.
-
Perhaps $ could be catenation as well as scalar reference?
Discrete scalars with or without intervening unescaped whitespace are
concatenated. '$' is used to make explicit the treatment of any
subexpression as a scalar.
$a = $b $" " $c;
$a = $b$c; # Tres DWIM, sir. And the shell programmers will get it.
$a = $b $ f(g($x));
@a = @b ^$ @c;
@a $= @b; # @a = @a $ @b, aka @a.push(@b);
$a $= $b; # $a = $a $ $b, or $a$b
> <$>
> <@>
> <%>
>
> would do something, too, because they look so pretty. :-D
>
Would you like breaktyping with that, sir?
=Austin
__
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/
Re: Perl6 Operator List
On Friday, October 25, 2002, at 01:00 PM, Larry Wall wrote:
Not clear how many of these are just universal or near-universal
methods.
Which would make some of them list-op variants, if we follow Perl 5
rules...
What's the Official Perl difference between a named unary op and a
one-arg universal method? E.g. why are "temp" and "let" both ops but
"my, our, hash" are not?
(I also missed 'err', not sure on that one either.)
: '...' "..." `...` /.../
:q qq qx qr qw
I'd still love to the double angles for a qw synonym.
'kay. As an aside, I've always itched for a qlike op that was
matrix-like, e.g.
my Pet @list = qm{
fido dog collie
fluffy cat siamese
};
But that's not quite working, because you usually need to pass the
attribute names in order for it to be meaningful. Maybe something
adverbial like:
my Pet @list = qm{
fido dog collie
fluffy cat siamese
} : << name type breed >>;
or even
my Pet @list = qm : << name type breed >> {
fido dog collie
fluffy cat siamese
};
That's still a lot easier to type than some of the alternatives I've
had to do for larger structures.
And I always wished
$=
@=
%=
<$>
<@>
<%>
would do something, too, because they look so pretty. :-D
Anyway, I'll revise and repost the list.
MikeL
Re: Perl6 Operator List
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 orxor
> :
> : .&.|.! - 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 in
Re: Perl6 Operator List
On Fri, Oct 25, 2002 at 11:27:54AM -0700, Michael Lazzaro wrote: > &&||!!//- boolean operations > &&= ||= !!= //= > and orxor Hmmm, given Larry's comments just now about about similar things not looking similar, I really think | vs ! is a mistake. From a distance, (14 inches in my case), they really do look almost indistinguable. (IMHO) -- "Strange women lying in ponds distributing swords is no basis for a system of government. Supreme executive power derives from a mandate from the masses, not from some farcical aquatic ceremony." Dennis - Monty Python and the Holy Grail.
Re: Perl6 Operator List
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 orxor
:
: .&.|.! - 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 unknow
Perl6 Operator List
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?
unary (prefix) operators:
\ - reference to
$ - dereference scalarref
@ - dereference arrayref
% - dereference hashref
& - dereference coderef
* - list flattening
? - force to bool context
! - force to bool context, negate
+ - force to numeric context
- - force to numeric context, negate
~ - force to string context
. - method call on current topic
-X - filetest operators
++ - preincrement
-- - predecrement
unary (postfix) operators:
++ - postincrement
-- - postdecrement
other postfix operators:
[] - array access
{} - hash access
hyperoperators:
^ - as prefix to any unary/binary operator, "vectorizes" the
operator
binary operators:
+ -*/%** x~<< >>
+= -= *= /= %= **= x= ~= <<= >>=
<><= => == != <=>
lt gt le ge eq ne cmp
&&||!!//- boolean operations
&&= ||= !!= //=
and orxor
.&.|.! - bitwise operations
.&= .|= .!=
& | ! - superpositional
all any one (none?)
~~ !~ - smartmatch and/or perl5 '=~' (?)
like unlike
=> - pair creator
, - list creator
; - "lesser comma", list-of-lists creator
: - adverbial
. - method call
.= - (?)
-> - like 'sub'
.. - range
... - yada**3
= - assignment
:= - binding
::= - binding, but more so
is
but
trinary operators:
?? ::
parens, misc, and quotelike operators:
()
m//
s/// - still around, but maybe shorthand for something else
tr///
'...' "..." `...` /.../
q qq qx qr qw
(heredocs) - (exact format unknown)
named unary (prefix) operators:
my our temp
not ref definedundef
length exists delete
sqrtlogsin cos tan
lc lcfirstuc ucfirst
int ordoct hex (bin?)
(...etc...)
MikeL
Re: [OT] Power of Lisp macros?
On 25 Oct 2002, Marco Baringer wrote: : Luke Palmer <[EMAIL PROTECTED]> writes: : >But think of what macros in general provide: : > : > * Multi-platform compatability : > * Easier maintenance : * Creating/Embedding custom languages. aka - adapting the : langauge to your problem domain. : : common lisp macros allow you to locally extend the vocabulary of : common lisp in the same way engineers have locally (ie within the : engineering domain) extended english with new syntax/semantics to deal : with engineering problems. Only up to a point. Engineers sometimes muck with the language at the parse level, before the macro processor even has a shot at it. Lisp gets away with this only because its syntax unambiguously distinguishes verbs from nouns. But engineers are always messing around with their word categories. How about using a verb as a predicate adjective: All systems are go for launch. That's probably derived from something more like: All systems are "go" for launch. So a macro system that takes preparsed text is still not powerful enough. It could be argued that you just pass in a string of data tokens without parentheses to get any arbitrary language, but you still can't parse a sentence like: All systems are ( for launch. : macros are functions which are run when the source code is read : (parsed). the argument to a macro is source code (expressed as a data : structure and not simple text) and the return value is source code : (not text). this is a fundamental difference between C's : text-processing macros, without this macros lose most of their power : and become too hard to write to be used. Yes, source filters have the same problem. : - what macros are really good at is embedding mini-languages and : creating new idioms, this often goes with, but is not nessecarily : related to, reducing lines of code. example: CLOS/MOP (common lisp : object system/meta object protocol) are implemented as macros on top : of non-OO lisp (this statement maybe be a lie if you go deep enough : into the specifics of some implementations). Support for mini-languages is a major design goal for Perl 6. : - the power of lisp's macros is that they allow you to perform : arbitrary code transformations by working with code as if it was : data. at one point there was discussion about having perl subs with : "auto-args" (i forget where i read about this) where by the : arguments to the sub where determined by parsing the body of the sub : itself and looking at what variables where used, this is a trivial : macro in lisp. adding this to perl5 required a source filter which : took forever to write and was never used because is was never : reliable enough (this may say more about my capabilities as a : programmer than about perl5 source filters). But we want auto-args by marking the args themselves, not by mentioning a special macro name in front. So support has to be built-in. : - everything you can do with macros you can do without, since macros : always get expaned (translated) into "regular" common lisp : code. however, sometimes (like with CPS) hand writing the output is : prohibitly difficult. Sure. : - some people consider macros to actually reduce maintainability since : they perform arbitrary code manipulations, so you have _no_ idea of : what is going on if you don't know what the macro does. macros which : introduce new symbols are especially vulnerable to this. Well, same is true of any built-in. But macros get really nasty if they cause your program to throw error messages that are impossible to understand. : - any sufficently powerful tool can be used to shot yourself in the : foot (or blow off your head). i doubt this java-esque argument : (let's "protect" the programmers from themselves) has any weight : with perl programmers, but it's something i've heard more than once. Actually, it has a lot of weight, but not in the sense of preventing Perl programmers from using the powerful features. What we really try to do is to avoid requiring the novice programmer to know abou the powerful features before they need to know them. If a Perl programmer has to do grammar munging in order to write a CGI script, something is terribly wrong. They might use a module that does grammar munging on their behalf, but that's different, because presumably someone else with more expertise wrote that module. So grammar munging is there to make life easier for today's source filter writers, not to make life harder for the novice. : - writing realiable/robust source filters is hard (do able, but hard, : even with The Damien's Filter::Simple). writing grammars is better, : but still hard, and more importantly, both require a rdically : different mind set from "regular" programming. the ease of writing : lisp macros is largely due to the fact that lisp has no syntax : (almost), and that
Re: [OT] Power of Lisp macros?
Angel Faus <[EMAIL PROTECTED]> writes: > Speaking about macros, I renember reading somewhere something about > Scheme hygenic macros, but i didn't really understood it. > > Do they solve the maintenance problems of Lisp macros? Would they be > applicable to perl? Scheme hygenic macros do a lot of the bookkeeping for you, so you don't have to muck about with gensym and are generally safe. The problem is (judging by what the Common Lisp types say, I don't have experience in this area myself), sometimes you need to do things that would be considered 'dangerous' and, unless the scheme implementation you're working with has some none standard extensions giving a scheme like C, you're up the well known creek without a paddle. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: [OT] Power of Lisp macros?
Speaking about macros, I renember reading somewhere something about Scheme hygenic macros, but i didn't really understood it. Do they solve the maintenance problems of Lisp macros? Would they be applicable to perl? Thanks for any tips, -angel
Re: [OT] Power of Lisp macros?
Luke Palmer <[EMAIL PROTECTED]> writes: > If you define "powerful" as "can do more things," then of course not. > Lisp is implemented in C, and C's macros are certainly not essential [aside: most "major" common lisp implementations (cmucl, sbcl, openmcl, mcl, allegro and lispworks) are all native compilers implemented in lisp (and some assembler for boot straping). CLISP is the only "major" implementation whose core is in fact implemented in a C dialect (for speed reasons (the virtual machine is really slow))] >But think of what macros in general provide: > > * Multi-platform compatability > * Easier maintenance * Creating/Embedding custom languages. aka - adapting the langauge to your problem domain. common lisp macros allow you to locally extend the vocabulary of common lisp in the same way engineers have locally (ie within the engineering domain) extended english with new syntax/semantics to deal with engineering problems. macros are functions which are run when the source code is read (parsed). the argument to a macro is source code (expressed as a data structure and not simple text) and the return value is source code (not text). this is a fundamental difference between C's text-processing macros, without this macros lose most of their power and become too hard to write to be used. common lisp's LOOP is a great example of what you can do with macros (and the best iteration construct around). see http://www.lispworks.com/reference/HyperSpec/Body/06_a.htm for the spec and http://www.ai.sri.com/~pkarp/loop.html for a tutorial. random points and counter-points: - what macros are really good at is embedding mini-languages and creating new idioms, this often goes with, but is not nessecarily related to, reducing lines of code. example: CLOS/MOP (common lisp object system/meta object protocol) are implemented as macros on top of non-OO lisp (this statement maybe be a lie if you go deep enough into the specifics of some implementations). - the power of lisp's macros is that they allow you to perform arbitrary code transformations by working with code as if it was data. at one point there was discussion about having perl subs with "auto-args" (i forget where i read about this) where by the arguments to the sub where determined by parsing the body of the sub itself and looking at what variables where used, this is a trivial macro in lisp. adding this to perl5 required a source filter which took forever to write and was never used because is was never reliable enough (this may say more about my capabilities as a programmer than about perl5 source filters). - everything you can do with macros you can do without, since macros always get expaned (translated) into "regular" common lisp code. however, sometimes (like with CPS) hand writing the output is prohibitly difficult. - some people consider macros to actually reduce maintainability since they perform arbitrary code manipulations, so you have _no_ idea of what is going on if you don't know what the macro does. macros which introduce new symbols are especially vulnerable to this. - any sufficently powerful tool can be used to shot yourself in the foot (or blow off your head). i doubt this java-esque argument (let's "protect" the programmers from themselves) has any weight with perl programmers, but it's something i've heard more than once. - writing realiable/robust source filters is hard (do able, but hard, even with The Damien's Filter::Simple). writing grammars is better, but still hard, and more importantly, both require a rdically different mind set from "regular" programming. the ease of writing lisp macros is largely due to the fact that lisp has no syntax (almost), and that lisp's syntax is programmable. perl6 will have the second and can't do much about the first (sort of goes against "different things should look different"). just another lurker's rant... -- -Marco Ring the bells that still can ring. Forget your perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen
Re: [OT] Power of Lisp macros?
On Wednesday 23 October 2002 17:58, Luke Palmer wrote: > > From: Adriano Nagelschmidt Rodrigues <[EMAIL PROTECTED]> >> [...] > > Do you think that Lisp macros make the language more powerful than > > others (eg Perl)? I mean, do they really give a competitive > > advantage, or are they being overrated (see below)? > > If you define "powerful" as "can do more things," then of course not. We're probably not talking about Turing-completeness here, so I'm not sure your point is valid. You sure can 'do more thing' in a language with Lisp-style macros (read _On Lisp_ and blow your mind). As for the competitive advantage etc., this does have a lot to see with the programmer. As for OOP or patterns or whatever, there is no silver bullet. > Lisp is implemented in C, and C's macros are certainly not essential > to its functionality. Humph. What does the fact that Lisp *can be* implemented in C have to see with C macros? BTW, it would be an insult to Lisp to compare C's macros to Lisp's macros. C macros are a stupid text replacement facility, they don't have anything to see with Lisp-style macros. > But think of what macros in general provide: > > * Multi-platform compatability > * Easier maintenance That's for C macros. It doesn't make much sense if you are talking about Lisp macros. > However, they are intending to make it possible to write things like > C with subs, which will imply most of the power of > macros... Well, if it means controling evaluation and making arbitrary code manipulation, then yes, probably... > though I imagine it won't be possible to have the level of > introspection lisp macros have (infinite). ? Manipulating arbitrary AST in Perl would be very complicated, those 'pesky' parenthesis in Lisp account for a lot of the magic that can go on while keeping things at a reasonable amount of complexity. Guillaume
Re: perl6 operator precedence table
On Thu, 24 Oct 2002, Larry Wall wrote:
> It's possible the syntax for substitution should be wrapped around the syntax
> for matching, whatever that turns out to be.
That strikes me as promising...
Going back to Perl5 for a moment, we have
substr($str,$start,$len) = $newstr
why not simply extend pattern-matching in a similar way to substr, making it
an L-value, so that one gets
$str ~ /[aeiou]+/ = "vowels($&)"
or
$str ~ /\d/ {hyper-symbol}= (0) x {size-of-LHS-array};
(hyper, however it's spelt, will have some way for the RHS to reference the
LHS, won't it?)
-Martin
--
4GL ... it's code Jim, but not as we know it.
