perl6 operator precedence table
John Williams
similar to the one in perlop.pod.
This is what I have come up with based on Apocalypse 3 and Exegesis 3.
Does anyone have comments? I'm not sure if the precedence
for : (adverb) or 'is' and 'but' are quite right.
perl6 operator precedence
left terms and list operators (leftward) [] {} () quotes
left . and unary .
nonassoc ++ --
left is but
right **
right ! \ and unary ~ + - * _
left =~ !~
left * / % x
left + - _
left << >>
right named unary operators, -X
left < > <= >= lt gt le ge == != <=> eq ne cmp
left &
left | ~
left &&
left || ~~ //
nonassoc .. ...
right ??::
right = := **= += -= _= *= /= %= x= &= |= ~=
<<= >>= &&= ||= ~~= //=
left , =>
left ;
left :
nonassoc list operators (rightward)
right not
left and
left or xor err
Here is a list of changes from perl5:
. becomes _
-> becomes .
== etc unified with < etc, and given left associativity
binary ^ becomes ~
?: becomes ??::
added ~~ // err
added ; with lower precedence than ,
added unary * and _ with same precedence as unary + -
added binary :=
added unary . with same precedence as binary .
( .foo === $self.foo )
added : (adverb operator) with low precedence(?)
print foo: $x, $y, $z; # lower than ,
my $fh = open $filepath : mode=>'rw'; # lower than =>
added 'is' and 'but' with high precedence(?)
my $thing is constant = 3 but false; # higher than =
Larry mentions that other precedence unifications are possible. I can see
the following as possibilites. Are there others?
& with &&
| with ||
<< >> with * /
~ John Williams
Sean O'Rourke
On Thu, 26 Sep 2002, John Williams wrote:
> perl6 operator precedence
>
> left terms and list operators (leftward) [] {} () quotes
> left . and unary .
> nonassoc ++ --
> left is but
This would lead to some scary things, I think:
$a = 3 + 4 but false
=> (= $a (+ 3 (but 4 false)))
Of course, so does having low precedence:
$a = 3 but false + 4
=> (= $a (but 3 (+ false 4)))
but I think the latter is unnatural enough that it deserves parens, so I'd
put 'but' above comma (and probably '='), but below just about everything
else.
> Larry mentions that other precedence unifications are possible. I can see
> the following as possibilites. Are there others?
> & with &&
> | with ||
It seems like a good idea to me to encourage people to think of bitwise
ops as mathematical, not logical, so I'd rather see them with different
precedences. Plus, anything that significantly goes against people's
hard-wired C expectations will just lead to confusion and pain. Finally,
having '|' below '&&' will probably lead to strange things, e.g.
1|2 && 3|4
=> 1 | (2 && 3) | 4
/s
Larry Wall
: Thanks for taking the time to write this out.
:
: On Thu, 26 Sep 2002, John Williams wrote:
: > perl6 operator precedence
: >
: > left terms and list operators (leftward) [] {} () quotes
: > left . and unary .
: > nonassoc ++ --
: > left is but
:
: This would lead to some scary things, I think:
:
: $a = 3 + 4 but false
: => (= $a (+ 3 (but 4 false)))
:
: Of course, so does having low precedence:
:
: $a = 3 but false + 4
: => (= $a (but 3 (+ false 4)))
:
: but I think the latter is unnatural enough that it deserves parens, so I'd
: put 'but' above comma (and probably '='), but below just about everything
: else.
Could perhaps unify with C<..>. Wouldn't hurt for it to be non-associative like C<..>.
: > Larry mentions that other precedence unifications are possible. I can see
: > the following as possibilites. Are there others?
: > & with &&
: > | with ||
:
: It seems like a good idea to me to encourage people to think of bitwise
: ops as mathematical, not logical, so I'd rather see them with different
: precedences. Plus, anything that significantly goes against people's
: hard-wired C expectations will just lead to confusion and pain. Finally,
: having '|' below '&&' will probably lead to strange things, e.g.
:
: 1|2 && 3|4
: => 1 | (2 && 3) | 4
I'd be more inclined to unify & and | with * and +, since that's
exactly what they are in Boolean algebra, where 1*1 == 1. I think
the argument that it breaks C compatibily is weak in this case,
since almost everyone admits that C is broken in this respect.
Alternately, we take | and & away from bitwise ops and do something
more useful with them. I have been asked privately by a sight
impaired person to consider using | as the separator for parallel
streams rather than the almost invisible ; character, for instance.
Being a bit sight impaired myself at the moment, I have great empathy...
Larry
Larry Wall
: similar to the one in perlop.pod.
:
: This is what I have come up with based on Apocalypse 3 and Exegesis 3.
: Does anyone have comments? I'm not sure if the precedence
: for : (adverb) or 'is' and 'but' are quite right.
Me either.
: perl6 operator precedence
:
: left terms and list operators (leftward) [] {} () quotes
: left . and unary .
Unary . can't be left associative. Perhaps unary . is nonassoc like ++.
: nonassoc ++ --
: left is but
Should probably be down about where .. is, maybe same as.
: right **
: right ! \ and unary ~ + - * _
Probably unary ? goes here too.
: left =~ !~
Probably should be the same as all the other comparison ops.
: left * / % x
And & maybe.
: left + - _
And | maybe.
: left << >>
Can be argued these are really just multiplicative. Or even exponential.
: right named unary operators, -X
: left < > <= >= lt gt le ge == != <=> eq ne cmp
: left &
: left | ~
Not sure what to do with ~ if we move & and |. Probably just follows |.
: left &&
: left || ~~ //
: nonassoc .. ...
Maybe "but" here. Maybe "is" too, though compile-time declarations
don't necessarily have the same syntactic constraints as ordinary
expressions.
: right ??::
: right = := **= += -= _= *= /= %= x= &= |= ~=
: <<= >>= &&= ||= ~~= //=
: left , =>
=> is no longer a comma. I think it has to be tighter than , now,
or we can't say
a => "a", b => "b"
Perhaps it goes in as another nonassoc .. operator.
: left ;
: left :
While semicolon is definitely looser than comma, it's not clear where
colon should go yet.
: nonassoc list operators (rightward)
: right not
I've also considered unifying C<not> with the list operators, which are
actually right associative, or you couldn't say
print sort 1,2,3;
On the other hand, it would be strange for C<not> to give its right
side a list context.
: left and
: left or xor err
Those are fine. :-)
Larry
Larry Wall
: : perl6 operator precedence
: :
: : left terms and list operators (leftward) [] {} () quotes
: : left . and unary .
:
: Unary . can't be left associative. Perhaps unary . is nonassoc like ++.
Actually, unary . has to be tighter than the binary one, or
.foo.bar
fires in the wrong order. If we make unary . like ++, then we'd have to move
binary . down below that for it to work. But maybe unary dot has to parse
exactly like binary dot with a missing left argument. In which case your
original analysis is closer to right.
It's a bit mind-blowing to think about doing that to the other unaries as well.
Larry
John Williams
> : but I think the latter is unnatural enough that it deserves parens, so I'd
> : put 'but' above comma (and probably '='), but below just about everything
> : else.
>
> Could perhaps unify with C<..>. Wouldn't hurt for it to be
> non-associative like C<..>.
'Is' and 'but' return their left operand to allow chaining, so don't 'is'
and 'but' need to be left associative so the following will work?
0 but true but string('zero rows affected')
> I'd be more inclined to unify & and | with * and +, since that's
> exactly what they are in Boolean algebra, where 1*1 == 1. I think
> the argument that it breaks C compatibily is weak in this case,
> since almost everyone admits that C is broken in this respect.
Good point.
> Alternately, we take | and & away from bitwise ops and do something
> more useful with them. I have been asked privately by a sight
> impaired person to consider using | as the separator for parallel
> streams rather than the almost invisible ; character, for instance.
> Being a bit sight impaired myself at the moment, I have great empathy...
| and & do one thing different from + and *. They impose integer context
on their operands, rather that just numeric.
How about moving ** down to just above *? There's no precedence from C,
and -$a**2 is a bit counter-intuitive mathematically. I'm not sure
what the intuitive behavior should be for the other unary operators
though.
I can post a revised table if the associativity of 'but' is clarified.
~ John Williams
my $zen = true but false;
Larry Wall
: On Tue, 8 Oct 2002, Larry Wall wrote:
:
: > : but I think the latter is unnatural enough that it deserves parens, so I'd
: > : put 'but' above comma (and probably '='), but below just about everything
: > : else.
: >
: > Could perhaps unify with C<..>. Wouldn't hurt for it to be
: > non-associative like C<..>.
:
: 'Is' and 'but' return their left operand to allow chaining, so don't 'is'
: and 'but' need to be left associative so the following will work?
:
: 0 but true but string('zero rows affected')
It might be clearer to require the parens there to disambiguate
(0 but true) but string('zero rows affected')
from
0 but (true but string('zero rows affected'))
But you're probably right that people will expect it to just stack more
properties on the leftmost argument.
: > I'd be more inclined to unify & and | with * and +, since that's
: > exactly what they are in Boolean algebra, where 1*1 == 1. I think
: > the argument that it breaks C compatibily is weak in this case,
: > since almost everyone admits that C is broken in this respect.
:
: Good point.
:
: > Alternately, we take | and & away from bitwise ops and do something
: > more useful with them. I have been asked privately by a sight
: > impaired person to consider using | as the separator for parallel
: > streams rather than the almost invisible ; character, for instance.
: > Being a bit sight impaired myself at the moment, I have great empathy...
:
: | and & do one thing different from + and *. They impose integer context
: on their operands, rather that just numeric.
Not if you use them on strings.
: How about moving ** down to just above *? There's no precedence from C,
: and -$a**2 is a bit counter-intuitive mathematically. I'm not sure
: what the intuitive behavior should be for the other unary operators
: though.
Seems to me we once had it that way, and people complained.
: I can post a revised table if the associativity of 'but' is clarified.
I wonder if we can combine .. with but. What if .. could also be
left associative? What would 1 .. 10 .. 10 mean? Maybe:
[1,2,3,4,5,6,7,8,9,10],
[2,3,4,5,6,7,8,9,10],
[3,4,5,6,7,8,9,10],
[4,5,6,7,8,9,10],
[5,6,7,8,9,10],
[6,7,8,9,10],
[7,8,9,10],
[8,9,10],
[9,10],
[10]
Hmm. I guess 1 .. (0 ..) would then mean something like:
[],
[1],
[1,2],
[1,2,3],
[1,2,3,4],
[1,2,3,4,5],
[1,2,3,4,5,6],
[1,2,3,4,5,6,7],
[1,2,3,4,5,6,7,8],
[1,2,3,4,5,6,7,8,9],
[1,2,3,4,5,6,7,8,9,10],
...
That strikes me as potentially useful to someone.
Larry
Aaron Crane
> Alternately, we take | and & away from bitwise ops and do something
> more useful with them.
I for one would be extremely happy to see that happen. Giving the bitwise
operations single-character names, while reasonable in the historical
context of (B and) C, suggests that they're useful way more often than they
actually are. (That applies particularly for a high-level language like
Perl, in my experience.)
I find the problem particularly apparent when delivering Perl training.
Many problem domains have little if any use for bitwise operations, and few
students have a background leading to familiarity with bitwise ops. What I
normally do is simply avoid teaching those operators to groups that won't
need them -- but there's often a student who's heard of them and who asks
questions about them.
Vaguely heretical, I know, but I'd be inclined to do something like this:
Perl 5 Proposed Perl 6
$x && $y $x & $y
$x || $y $x | $y
$x & $y bitand($x, $y)
$x | $y bitor($x, $y)
Using functions instead of operators for these operations seems reasonable
to me given how often they're useful. I'm not especially fond of the names
bitand and bitor, but they're accurate, reasonably short, and have prior art
in C and C++.
Two things about this proposal:
* This leaves && and || available for other purposes, but I can't off the
top of my head think of anything else I'd want them for.
* Does this make it harder to write overloaded bitwise ops for your
classes?
--
Aaron Crane * GBdirect Ltd.
http://training.gbdirect.co.uk/courses/perl/
Jonathan Scott Duff
> Vaguely heretical, I know, but I'd be inclined to do something like this:
>
> Perl 5 Proposed Perl 6
> $x && $y $x & $y
> $x || $y $x | $y
Larry just added nice character doubling ops to be more consistent and
here you want to take two of them away? :-)
> $x & $y bitand($x, $y)
> $x | $y bitor($x, $y)
>
> Using functions instead of operators for these operations seems reasonable
> to me given how often they're useful.
How about these?
$x band $y
$x bor $y
Of course, then people will probably expect these too:
$x bshl $y
$x bshr $y
$x bxor $y
Hrm ...
sysopen(FOO,"foo", O_WRONLY bor O_CREAT bor O_TEXT)
sysopen(FOO,"foo", bor O_WRONLY, O_CREAT, O_TEXT)
:-(
As long as we're in fantasy-land, how about these?
$x .& $y
$x .| $y
Those look like bit operations to me :-)
> I'm not especially fond of the names bitand and bitor, but they're
> accurate, reasonably short, and have prior art in C and C++.
Not all prior art is necessarily good art :-)
> Two things about this proposal:
>
> * This leaves && and || available for other purposes, but I can't
> off the top of my head think of anything else I'd want them for.
Then why muck with them? Just munge the bitwise operators.
> * Does this make it harder to write overloaded bitwise ops for your
> classes?
No harder than it was before especially given that you can warp the
syntax however you please.
-Scott
--
Jonathan Scott Duff
du...@cbi.tamucc.edu
Larry Wall
: On Fri, Oct 11, 2002 at 03:21:38PM +0100, Aaron Crane wrote:
: > Vaguely heretical, I know, but I'd be inclined to do something like this:
: >
: > Perl 5 Proposed Perl 6
: > $x && $y $x & $y
: > $x || $y $x | $y
:
: Larry just added nice character doubling ops to be more consistent and
: here you want to take two of them away? :-)
I doubt I'd muck with the doubled ones.
I'm wondering whether the single ones could indicate parallel streams.
We had the difficulty of specifying whether the C<for> loop should
terminate on the shorter or the longer stream. We could say that |
terminates on the longer, and & on the shorter. Possibly there's
some relationship with any() and all() in there as well. The | could
generally be construed as a comma that doesn't guarantee ordering.
So cases could be written
when 1 | 2 | 3 {...}
as well as with comma. Saying
when 1 & 2 & 3 {...}
might be short for
when all(1,2,3) {...}
: > $x & $y bitand($x, $y)
: > $x | $y bitor($x, $y)
: >
: > Using functions instead of operators for these operations seems reasonable
: > to me given how often they're useful.
:
: How about these?
:
: $x band $y
: $x bor $y
:
: Of course, then people will probably expect these too:
:
: $x bshl $y
: $x bshr $y
: $x bxor $y
:
: Hrm ...
:
: sysopen(FOO,"foo", O_WRONLY bor O_CREAT bor O_TEXT)
: sysopen(FOO,"foo", bor O_WRONLY, O_CREAT, O_TEXT)
:
: :-(
:
: As long as we're in fantasy-land, how about these?
:
: $x .& $y
: $x .| $y
I was thinking more along the lines of:
$x &&& $y
$x ||| $y
But then there's ~ vs ~~~ too. The triple syntax at least has the
virtue of the visual metaphor of doing a bunch of ANDs or ORs in
parallel. But it's kind of odd to write ~~~$x for a one's complement.
Anyone else want to be UNSUBSCRIBED IMMEDIATELY? :-)
: Those look like bit operations to me :-)
:
: > I'm not especially fond of the names bitand and bitor, but they're
: > accurate, reasonably short, and have prior art in C and C++.
:
: Not all prior art is necessarily good art :-)
:
: > Two things about this proposal:
: >
: > * This leaves && and || available for other purposes, but I can't
: > off the top of my head think of anything else I'd want them for.
:
: Then why muck with them? Just munge the bitwise operators.
:
: > * Does this make it harder to write overloaded bitwise ops for your
: > classes?
:
: No harder than it was before especially given that you can warp the
: syntax however you please.
No warpage necessary. All operators can be named as functions with
operator: on the front.
Larry
Luke Palmer
> From: Larry Wall <la...@wall.org>
>
> I'm wondering whether the single ones could indicate parallel streams.
> We had the difficulty of specifying whether the C<for> loop should
> terminate on the shorter or the longer stream. We could say that |
> terminates on the longer, and & on the shorter. Possibly there's
> some relationship with any() and all() in there as well. The | could
> generally be construed as a comma that doesn't guarantee ordering.
> So cases could be written
>
> when 1 | 2 | 3 {...}
>
> as well as with comma. Saying
>
> when 1 & 2 & 3 {...}
>
> might be short for
>
> when all(1,2,3) {...}
Aha! Superpositions. | is for any, & is for all. That works :).
Some of my students want to go:
if ($x == 1 || 2) { ... }
Now they can:
if $x == 1 | 2 { ... }
It reads well in english (which I am a strong supporter of). Better
than "if x equals any one two." I do very much like this idea.
Luke
Simon Cozens
> I was thinking more along the lines of:
>
> $x &&& $y
> $x ||| $y
This isn't Perl; this is merely some language that looks a bit like
it. I can understand the attraction for confusing anyone who comes
from a standard Unix language background, but I'm not sure it's a
great idea, all told.
--
By God I *KNOW* what this network is for, and you can't have it.
- Russ Allbery, http://www.eyrie.org/~eagle/writing/rant.html
Simon Cozens
> I'm not sure either, and that's why I'm thinking about it. :-)
Phew.
--
Only two things are infinite: the Universe and human stupidity, and I'm
not sure about the former - Albert Einstein
Larry Wall
: la...@wall.org (Larry Wall) writes:
: > I was thinking more along the lines of:
: >
: > $x &&& $y
: > $x ||| $y
:
: This isn't Perl; this is merely some language that looks a bit like
: it. I can understand the attraction for confusing anyone who comes
: from a standard Unix language background, but I'm not sure it's a
: great idea, all told.
I'm not sure either, and that's why I'm thinking about it. :-)
Larry
Dan Sugalski
I think that, for me at least, it'll be close enough to C to be
really confusing. (I already have the problem of leaving parens off
of my function calls when I write XS code...) There's a certain
appeal to not having to swap in almost-but-not-quite-the-same sets of
punctuations when moving from language to language.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Larry Wall
: I think that, for me at least, it'll be close enough to C to be
: of my function calls when I write XS code...) There's a certain
: appeal to not having to swap in almost-but-not-quite-the-same sets of
: punctuations when moving from language to language.
And now for something completely not quite different...
bits($x & $y)
bits($x | $y)
That is, bits() could just be a function that takes a superposition
and interprets it as bitops, which makes an odd kind of sense.
Or we could fix the "if this number was never used as a string"
problem by differentiating integer ops from string ops:
intbits($x & $y)
intbits($x | $y)
strbits($x & $y)
strbits($x | $y)
One could maybe shrink that down to
int($x & $y)
int($x | $y)
str($x & $y)
str($x | $y)
Except that's not really much different than:
+($x & $y)
+($x | $y)
_($x & $y)
_($x | $y)
And that would conflict with Damian's current notions of how superpositions
behave in numeric or string context. Still, you can see how
bits(1|2|4|8)
could be made to work even if it really meant
bits(any(1,2,4,8))
Larry, still thinking about a language vaguely resembling Perl 5. :-)
Dan Kogai
> Vaguely heretical, I know, but I'd be inclined to do something like
> this:
>
> Perl 5 Proposed Perl 6
> $x && $y $x & $y
> $x || $y $x | $y
>
> $x & $y bitand($x, $y)
> $x | $y bitor($x, $y)
Objection, your honor.
perl5 ($x & $y) might be uncommon enough to justify this. But how
about &= vs. &&=, |= vs. ||= ? Those are both used very often so by
saving one symbol we lose consistency.
Dan |= MAN | FATHER | PERL5POTER | tobe->user->(PERL6)
Larry Wall
: Objection, your honor.
:
: perl5 ($x & $y) might be uncommon enough to justify this. But how
: about &= vs. &&=, |= vs. ||= ? Those are both used very often so by
: saving one symbol we lose consistency.
Ouch. You're right. That's a bit of a problem for bits($x | $y) too.
Hmm.
@a ^|||= 1;
@a ^bor= 1;
@a ^.|= 1;
Yow. Those are all pretty ugly. But the first one is the least ugly.
And I really do like | for any(). And I can see using it like this:
@cases ^|= @newcases;
to mean
for @cases | @newcases -> $x is rw | $y {
$x = any($x, $y);
}
Another question is whether using a superposition to represent parallel
streams in "for" is doing the "any" concept too much violence. Really,
it's more of a hyper-any, at least on the left:
for @cases ^| @newcases -> $x is rw | $y {...}
But note that ^& automatically gives us the shorter of the two lists.
Maybe...
Just thinking... :-)
Larry
Aaron Crane
> Some of my students want to go:
>
> if ($x == 1 || 2) { ... }
>
> Now they can:
>
> if $x == 1 | 2 { ... }
I like that a lot. (Some of my students also want to do that.)
You can write an equivalent thing in Icon:
if x = (0 | 1)
though (if memory serves) the parens are required. And in Icon it's done
with backtracking, not superpositions.
Fearcadi
http://archive.develooper.com/perl6-language%40perl.org/msg11440.html
Larry Wall wrote:
>I'm wondering whether the single ones could indicate parallel streams.
>We had the difficulty of specifying whether the C<for> loop should
>terminate on the shorter or the longer stream. We could say that |
>terminates on the longer, and & on the shorter. Possibly there's
>some relationship with any() and all() in there as well. The | could
>generally be construed as a comma that doesn't guarantee ordering.
>So cases could be written
but then in the "for" loop @a | @b should result in *ordered*
any(@a,@b) because we need to distinguish the first and second stream when
attaching to the arguments of -> ... closure.
While inside when @a|@b results in unordered any(...).
How this lives together?
arcadi.
Fearcadi
http://archive.develooper.com/perl6-language%40perl.org/msg11451.html
Larry Wall wrote:
> for @cases ^| @newcases -> $x is rw | $y {...}
do I understand correctly that what happens is (more or less) --
any($a,$b) := any($x,$y)
?
arcadi
Larry Wall
: Luke Palmer writes:
: > Some of my students want to go:
: >
: > if ($x == 1 || 2) { ... }
: >
: > Now they can:
: >
: > if $x == 1 | 2 { ... }
:
: I like that a lot. (Some of my students also want to do that.)
:
: You can write an equivalent thing in Icon:
:
: if x = (0 | 1)
:
: though (if memory serves) the parens are required. And in Icon it's done
: with backtracking, not superpositions.
The optimizer could certainly choose to implement it with backtracking
if that was deemed to be more efficient and just as correct. The big
value of superpositions is that they're a declarative syntax for
something that would otherwise have to be specified procedurally.
But everything ends up procedural underneath, at least with our
current computers.
I think that any() really needs to avoid making any guarantees
about whether (and in what order) its arguments are evaluated.
(Use || if you want to be sure.) In a sense, that's the way
QM-based nanomachinery works anyway--progress is never guaranteed
unless an external constraint is met. In other words, you just
run probabistically on Brownian motion until something "latches".
Proteins just happen to be very good at latching.
Larry
Larry Wall
: in
The | or & doesn't really indicate a superposition in the C<for>.
All I meant by "unordered" was that it was not guaranteed that @a is
evaluated before @b, so they could in theory be evaluated in separate
subthreads. The C<for> loop would just be "stealing" the |/& notation
because it's convenient to be able to distinguish whether both values
have to be there or only one for the loop to continue. The streams
would stay discrete, however. And the $a | $b in the declaration
would likewise not be producing an any(). It's just a funny kind of
anchor to pattern match the formal args against the actual args.
But we haven't thought through all the ramifications yet, so it may
yet turn out to be a bad idea.
Larry
Fearcadi
>And I really do like | for any(). And I can see using it like this:
>
> @cases ^|= @newcases;
>
>to mean
>
> $x = any($x, $y);
> }
>
but then probably we should also have
@cases = @cases ^| @newcases; is same as ( @cases ^|= @newcases; )
@cases = @cases ^, @newcases; is same as ( @cases ^,= @newcases; )
the second creates a list of two-element arrays which may be useful.
>Another question is whether using a superposition to represent parallel
>streams in "for" is doing the "any" concept too much violence. Really,
>it's more of a hyper-any, at least on the left:
>
> for @cases ^| @newcases -> $x is rw | $y {...}
>
>But note that ^& automatically gives us the shorter of the two lists.
>
in analogy, may be here
for @cases ^, @newcases -> $x is rw , $y {...}
will do the job . though not clear what happens when arrays have different
length. which proves that | is just special comma.
print >>arcadi =~ s/Larry/arcadi/ ;
>Maybe...
>
>Just thinking... :-)
>
>Larry
>
arcadi
Smylers
> I was thinking more along the lines of:
>
> $x &&& $y
> $x ||| $y
I very much like the new suggested uses for C<&> and C<|>, and making
the rarely-useful bitwise ops be longer to type.
But I'm not keen on trippled symbols: I reckon it's two easier to muddle
them with their doubled counterparts when scanning code, much easier
than it is to confuse single and doubled symbols. The C<==> and C<===>
distinction in PHP is not easy to spot.
> But then there's ~ vs ~~~ too.
That gave me an idea. What about using the tilde as the first character
in bitwise ops?
$x ~& $y # bitwise and
$x ~| $y # bitwise or
~!$x # bitwise not
Smylers
Larry Wall
:
: That gave me an idea. What about using the tilde as the first character
: in bitwise ops?
:
: $x ~& $y # bitwise and
: $x ~| $y # bitwise or
:
: ~!$x # bitwise not
I think I like that. Except now we'll get things like:
@x ^~|= @y;
Hmm...and then there's:
$a ~? $b ~: $c
And what's bitwise xor? I suppose it could also be ~!, but as a
binary operator. Unfortunately, that say's that high-level logical
xor should be !!, rather than ~~.
Larry
Smylers
> : $x ~& $y # bitwise and
> : $x ~| $y # bitwise or
> :
> : ~!$x # bitwise not
>
> I think I like that. Except now we'll get things like:
>
> @x ^~|= @y;
>
> Hmm...and then there's:
>
> $a ~? $b ~: $c
I don't think they're too problematic. Most people shouldn't need to
know the bitwise stuff, and for those who do a consistent prefix makes
it easier to learn.
It's rare enough to need bitwise things in Perl 5 (outside golf). I'm
hoping that it'll be even rarer in Perl 6, as better interfaces are
designed for the things which at present require flipping individual
bits.
> And what's bitwise xor?
How about keeping caret for xor?
$a ~^ $b # bitwise xor
$a ^^ $b # logical xor
I don't think those will clash with the hyper operator.
Hmmm. I'm not sure they look sufficiently different from each other
though. And it does lead to:
@a ^^^ @b
@a ^~^ @b
The first of those contains a tripled operator (the thing I was trying
to avoid when I started this suggestion).
And both of them run the risk of looking like they're underlining
whatever's on the line above rather than being operators ...
Smylers
David Wheeler
> How about keeping caret for xor?
>
> $a ~^ $b # bitwise xor
> $a ^^ $b # logical xor
Hm, the "seagull operator"?
David
--
David Wheeler AIM: dwTheory
da...@wheeler.net ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: The...@jabber.org
Larry Wall
: Larry Wall wrote:
:
: > : $x ~& $y # bitwise and
: > : $x ~| $y # bitwise or
: > :
: > : ~!$x # bitwise not
: >
: > I think I like that. Except now we'll get things like:
: >
: > @x ^~|= @y;
: >
: > Hmm...and then there's:
: >
: > $a ~? $b ~: $c
:
: I don't think they're too problematic. Most people shouldn't need to
: know the bitwise stuff, and for those who do a consistent prefix makes
: it easier to learn.
True. In linguistics we would call it a "productive" prefix, meaning you
can generate new words using it.
: It's rare enough to need bitwise things in Perl 5 (outside golf). I'm
: hoping that it'll be even rarer in Perl 6, as better interfaces are
: designed for the things which at present require flipping individual
: bits.
I almost wonder if it's wrong to waste ~ on it...
That would be an argument for b| and b&, I suppose.
: > And what's bitwise xor?
:
: How about keeping caret for xor?
:
: $a ~^ $b # bitwise xor
: $a ^^ $b # logical xor
:
: I don't think those will clash with the hyper operator.
Depends on whether Damain decides he needs ^ as a superposed "exclusive or"
to go with & and |. That would make ^^ a hyper super xor.
: Hmmm. I'm not sure they look sufficiently different from each other
: though. And it does lead to:
:
: @a ^^^ @b
: @a ^~^ @b
:
: The first of those contains a tripled operator (the thing I was trying
: to avoid when I started this suggestion).
We may well make ^ a separable prefix, so you could write @a ^ ^^ @b.
But it still seems a bit confusing to have two different meanings for ^.
: And both of them run the risk of looking like they're underlining
: whatever's on the line above rather than being operators ...
Score one for using !. Binary !! for xor would be snazzy. And Damian
could have binary ! for super xor if he wants it, and if we don't swipe
it for a unary postfix of some sort.
By the way, we could also allow space in an assignment op, so that
@x ^~|= @y;
could be written:
@x ^ ~| = @y;
But I'm not sure that's an improvement...
Larry
Adam D. Lopresto
> : hoping that it'll be even rarer in Perl 6, as better interfaces are
> : designed for the things which at present require flipping individual
> : bits.
>
> I almost wonder if it's wrong to waste ~ on it...
>
> That would be an argument for b| and b&, I suppose.
That looks like about the best. When rare things get too punctuation-heavy,
people start to get really confused. What I'd expect is that a lot of what's
now done bitwise could be done with overloading of superpositions (combining
flags and such, although in a lot of cases & and | would be swapped. Then
again, it always seemed odd that you combine two flags with | to turn them both
on). There could probably be a bitwise type that would overload superpositions
to do bitwise math instead...
my Bitwise $a = 1; #woohoo, $a and $b are no longer magical!
my Bitwise $b = 3;
print $a & $b; #prints 3
So if you really need to do a lot of bitmath, you use the special types, and
otherwise you can be barely aware that they exist.
sysopen($handle, $filenmae, O_CREAT & O_RDRW);
--
Adam Lopresto (ad...@cec.wustl.edu)
http://cec.wustl.edu/~adam/
"We've secretly replaced the dilithium with Folgers Crystals."
John Williams
> > : It's rare enough to need bitwise things in Perl 5 (outside golf). I'm
> > : hoping that it'll be even rarer in Perl 6, as better interfaces are
> > : designed for the things which at present require flipping individual
> > : bits.
> >
> > I almost wonder if it's wrong to waste ~ on it...
> >
> > That would be an argument for b| and b&, I suppose.
>
> That looks like about the best. When rare things get too punctuation-heavy,
> people start to get really confused.
I agree. b| and b& are the first operators which look good to me. Most
of the other proposals look like line-noise, and I would hate to have to
start agreeing with perl-detractors. Bitand and and bitor work for me
too.
~ John Williams
Jonathan Shapiro
Well, let's look at a few possibilities:
1) if( $vec bit| $mask bit& $mask2 )
2) if( $vec b| $mask b& $mask2 )
3) if( $vec |b $mask &b $mask2 )
4) if( $vec |bit $mask &bit $mask2 )
I think I would have an easier time explaining #4 to someone
(
"What does the 'b' stand for?"
"It stands for 'bit'"
"Why not just write 'bit' then'?" )
Plus, what is '|bit'? It's an 'or' operator primarily, and it's of the 'bit'
flavor. 'Though I'm guessing that asking to have an operator whose first
character is '&' is Perl heresy. I just thought it was interesting to see
what it would look like in code.
-Jonathan Shapiro
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
Larry Wall
: Then again, it always seemed odd that you combine two flags with | to turn them both
: on). There could probably be a bitwise type that would overload superpositions
: to do bitwise math instead...
:
: my Bitwise $a = 1; #woohoo, $a and $b are no longer magical!
: my Bitwise $b = 3;
:
: print $a & $b; #prints 3
:
: So if you really need to do a lot of bitmath, you use the special types, and
: otherwise you can be barely aware that they exist.
Yeah, I've been thinking about that approach for several days now.
The main problem I see with it is that sometimes you want to view
an integer as a superposition, and sometimes not. Someone might be
surprised when they use $b in a case and discover it's matching 1|2
rather than 3.
: sysopen($handle, $filenmae, O_CREAT & O_RDRW);
Nothing says that actually has to do bit math! This could also be
made to work:
sysopen($handle, $filenmae, "create" & "rdrw");
Could even make something like this work:
sysopen($handle, $filenmae, "exists" & "append"
| "create" & "rdrw");
One could go as far as to make a superposition of lvalues do unification.
But I think we need to keep superpositions separate from bitops because of
the and/or confusion you noted.
Larry
Brent Dax
# Well, let's look at a few possibilities:
#
# 1) if( $vec bit| $mask bit& $mask2 )
#
# 2) if( $vec b| $mask b& $mask2 )
#
# 3) if( $vec |b $mask &b $mask2 )
#
# 4) if( $vec |bit $mask &bit $mask2 )
What's wrong with 'bitand' and 'bitor' (or even 'mask' and 'combine', or
something to that effect)?
5) if( $vec bitor $mask bitand $mask )
6) if( $vec combine $mask mask $mask )
--Brent Dax <bren...@cpan.org>
@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)
David Wheeler
> Well, let's look at a few possibilities:
>
> 1) if( $vec bit| $mask bit& $mask2 )
>
> 2) if( $vec b| $mask b& $mask2 )
>
> 3) if( $vec |b $mask &b $mask2 )
>
> 4) if( $vec |bit $mask &bit $mask2 )
>
> I think I would have an easier time explaining #4 to someone
Yes, except that &bit is a subroutine reference, IIRC, not an operator.
That's why it makes more sense to put the punctuation character at the
end of the operator name.
Regards,
Larry Wall
: On Thursday, October 17, 2002, at 11:49 AM, Shapiro, Jonathan wrote:
:
: > Well, let's look at a few possibilities:
: >
: > 1) if( $vec bit| $mask bit& $mask2 )
: >
: > 2) if( $vec b| $mask b& $mask2 )
: >
: > 3) if( $vec |b $mask &b $mask2 )
: >
: > 4) if( $vec |bit $mask &bit $mask2 )
: >
: > I think I would have an easier time explaining #4 to someone
:
: Yes, except that &bit is a subroutine reference, IIRC, not an operator.
: That's why it makes more sense to put the punctuation character at the
: end of the operator name.
Here's another approach:
my @a is bitmap($a);
my @b is bitmap($b);
my @c is bitmap($c);
@a = @b ^| @c;
and then you get
shift @a;
for free.
Larry
Larry Wall
: Shapiro, Jonathan:
: # Well, let's look at a few possibilities:
: #
: # 1) if( $vec bit| $mask bit& $mask2 )
: #
: # 2) if( $vec b| $mask b& $mask2 )
: #
: # 3) if( $vec |b $mask &b $mask2 )
: #
: # 4) if( $vec |bit $mask &bit $mask2 )
:
: What's wrong with 'bitand' and 'bitor' (or even 'mask' and 'combine', or
: something to that effect)?
:
: 5) if( $vec bitor $mask bitand $mask )
:
: 6) if( $vec combine $mask mask $mask )
I find those difficult to read--too wordy. At the moment I'm leaning towards
$a .| $b # bitwise or
$a .& $b # bitwise and
$a .! $b # bitwise xor
.! $b # bitwise not
$a ! $b # logical xor
! $b # logical not
I think the "." looks kind of like a bit. A ":" would also work, and risk
less confusion with method call syntax. But the "." is better at getting out
of the way visually. As a productive prefix, it has limits, but there are
actually very few operators that make sense to be bitified, and none of them
look like a method name.
I like the notion that binary ! means that the two sides are sharing one "not".
That's the definition of XOR in a nutshell.
I also like the idea that ~ is entirely freed up for some other nefarious use.
Larry
Jonathan Scott Duff
> I find those difficult to read--too wordy. At the moment I'm leaning towards
>
> $a .| $b # bitwise or
> $a .& $b # bitwise and
> $a .! $b # bitwise xor
> .! $b # bitwise not
> $a ! $b # logical xor
> ! $b # logical not
>
> I think the "." looks kind of like a bit. A ":" would also work, and risk
> less confusion with method call syntax. But the "." is better at getting out
> of the way visually.
I knew you'd see things my way eventually :-)
> As a productive prefix, it has limits, but there are actually very few
> operators that make sense to be bitified, and none of them look like a
> method name.
Could users redefine how the prefixes work and get the productions for
free? If so, a whole crop of unanticipated bit operators might come
into play.
> I like the notion that binary ! means that the two sides are sharing
> one "not". That's the definition of XOR in a nutshell.
>
> I also like the idea that ~ is entirely freed up for some other
> nefarious use.
Neat x 2
-Scott
--
Jonathan Scott Duff
du...@cbi.tamucc.edu
Smylers
> $a .| $b # bitwise or
> $a .! $b # bitwise xor
On glancing down your list I initially misread the bar as an exclamation
mark. I realize that this is a sample size of one, but certainly in
this terminal font those only differ by a single pixel and it's possible
that this could become a source of confusion.
I actually like the suggestion. Also, I'm seriously hoping never to do
any bitwise stuff in Perl 6, so I'm not objecting to it.
Smylers
Mark J. Reed
> Larry Wall wrote:
>
> > $a .| $b # bitwise or
> > $a .! $b # bitwise xor
>
> On glancing down your list I initially misread the bar as an exclamation
> mark. I realize that this is a sample size of one, but certainly in
> this terminal font those only differ by a single pixel and it's possible
> that this could become a source of confusion.
increased by the period; in this font
(X11 fd: misc-fixed-medium-r-normal--20-200-75-75-c-100-iso10646-1),
the period is notably larger than the dot of the exclamation point, which
visually reduces the significance of that tiny gap.
This wasn't a problem in Perl5 becuase ! and | could be distinguished
by context; there was no binary ! or unary | (unless you count the pipe
syntax of open(), but there again you have a visually distinct context).
As soon as you introduce one or the other of those you have a very
subtle visual distinction going on.
--
Mark REED | CNN Internet Technology
1 CNN Center Rm SW0831G | mark...@cnn.com
Atlanta, GA 30348 USA | +1 404 827 4754
Larry Wall
: > As a productive prefix, it has limits, but there are actually very few
: > operators that make sense to be bitified, and none of them look like a
: > method name.
:
: Could users redefine how the prefixes work and get the productions for
: free? If so, a whole crop of unanticipated bit operators might come
: into play.
Well, anything is possible if you mung the grammar, but but I don't
see how dot could be made into a general prefix like hyper, or you'd
mess up things like .[] and .{}.
Larry
Smylers
> $a .! $b # bitwise xor
> $a ! $b # logical xor
> ! $b # logical not
>
> I like the notion that binary ! means that the two sides are sharing
> one "not". That's the definition of XOR in a nutshell.
I like that too. It also means that C<!!> and C<.!!> become the
equivalence operators for free. (Technically inverting the right
operand then doing xor, but that's ... um, equivalent.)
However it means that the binary ops become:
$a || $b # logical or
$a .| $b # bitwise or
$a && $b # logical and
$a .& $b # bitwise and
$a ! $b # logical xor
$a .! $b # bitwise xor
That makes logical xor look a little inconsistent (it doesn't line up
for a start).
Doubling the exclamation mark would make logical xor fit in better
(though that'd leave three of them in equivalence).
> I also like the idea that ~ is entirely freed up for some other
> nefarious use.
Yeah; how'd that happen? Seems like not too long ago we were short of
punctuation symbols, and now you've got a spare one lying around.
Smylers
Smylers
> On 2002-10-17 at 22:52:49, Smylers wrote:
>
> > ... I initially misread the bar as an exclamation mark. I realize
> > that this is a sample size of one ...
>
> Make that a sample size of two.
Well, not really. (Presumably there are many other people who also read
Larry's mail without any problems.)
> I think the confusion is actually increased by the period; in this
> font (X11 fd:
> misc-fixed-medium-r-normal--20-200-75-75-c-100-iso10646-1), the period
> is notably larger than the dot of the exclamation point, which
> visually reduces the significance of that tiny gap.
Ah yes. (I'm using a different variant of the same typeface.) If the
font had got a full-stop-sized dot on the bottom of the exclamation (and
question) mark there wouldn't be a problem.
In which case, I withdraw my objection:
* Perl has to make a working assumption that, in general, different
characters look different; if they don't, that's the typeface's
problem not Perl's.
If we pander to every possible conflict that might occur in any
typeface, there'll be very few characters left to use. (For example
in the default Courier font used by 'KEdit' braces look like square
brackets, but we blatantly need to have both of those in the
language.)
And xor isn't particularly common, so the scope for confusion would
be limited.
* I _can_ tell the difference, once I look properly, even in this
font. I was concerned that those with vision difficulties may not
be able to do so. But presumably such people will choose more
sensible typefaces (and probably larger ones).
Somebody fairly recently recommended some decent fixed-width typefaces.
I think it may have been MJD, but I can't find the reference right now
(could be at work).
Smylers
Smylers
> > Somebody fairly recently recommended some decent fixed-width
> > typefaces. I think it may have been MJD ...
>
> Michael Schwern recently suggested "Monaco, Neep or, if you can find
> them, Mishawaka or ProFont".
Ah, yes. That's what I was failing to recollect. (Apologies to both
MJD and Schwern ...)
> I investigated and found this link to be useful:
>
> http://www.tobias-jung.de/seekingprofont/
Ta.
Smylers
Me
typefaces.
> I think it may have been MJD, but I can't find the reference right now
> (could be at work).
Michael Schwern recently suggested "Monaco,
Neep or, if you can find them, Mishawaka or ProFont".
I investigated and found this link to be useful:
http://www.tobias-jung.de/seekingprofont/
--
ralph
Larry Wall
: However it means that the binary ops become:
:
: $a || $b # logical or
: $a .| $b # bitwise or
: $a && $b # logical and
: $a .& $b # bitwise and
: $a ! $b # logical xor
: $a .! $b # bitwise xor
:
: That makes logical xor look a little inconsistent (it doesn't line up
: for a start).
:
: Doubling the exclamation mark would make logical xor fit in better
: (though that'd leave three of them in equivalence).
On top of which, Damian has expressed an interest in ! for a superpositional xor.
So the logical is probably !!. Plus it's actutally easier to see the missing bits
when there's two of them.
: > I also like the idea that ~ is entirely freed up for some other
: > nefarious use.
:
: Yeah; how'd that happen? Seems like not too long ago we were short of
: punctuation symbols, and now you've got a spare one lying around.
Pity there's no extra brackets lying around without going to Unicode...
Larry
Luke Palmer
> From: Larry Wall <la...@wall.org>
> On top of which, Damian has expressed an interest in ! for a
> superpositional xor.
Which would behave how, exactly?
Luke
Damian Conway
>>superpositional xor.
>
> Which would behave how, exactly?
Well, that's still a matter for conjecture.
N-ary xor isn't particularly useful, because binary xor naturally generalizes
to: "an odd number of these N operands are true". (Hint: think about the
truth table for logical C<$a !! $b !! $c>).
An alternate interpretation of generalized xor is that it means
"exactly one of these N operands is true". That's what I envisage
superpositional C<!> doing:
Function Operator
any |
all &
one !
So you could write:
if $x1 ! $x2 ! $x3 == 0 {
print "Cubic equation has a unique root\n";
}
or:
$nonrepeated = any(@value) == one(@value);
or:
$second_biggest = any(@value) < one(@value);
None of these makes C<one>/C<!> as essential as C<any> or C<all>, but:
(a) someone smarter than me will almost certainly
find a killer app for C<one>,
(b) the symmetry of:
Logical: && || !!
Bitwise: .& .| .!
Superpositional: & | !
is important...mnemonically, DWIMically, and aesthetically.
Damian
Miko O'Sullivan
> > superpositional xor.
>
> Which would behave how, exactly?
! the way people expect, I fear.
-Miko
Brent Dax
# : > I also like the idea that ~ is entirely freed up for some other
# : > nefarious use.
# :
# : Yeah; how'd that happen? Seems like not too long ago we
# were short of
# : punctuation symbols, and now you've got a spare one lying around.
#
# Pity there's no extra brackets lying around without going to
# Unicode...
Can the new nefarious use be concat? Pretty please?
Damian Conway
> Can the new nefarious use be concat? Pretty please?
There was a brief period 18 months ago when tilde *was* the designated
Perl 6 concatenation operator.
I certainly wouldn't mind seeing it return to that role, now that
it's not needed elsewhere. And, of course, that would actually be:
$x ~ $y string concatentation
$x ~= $y string append
~$x stringification
I guess the only concern is the potential for nasty surprises between:
$str =~ s/a/b/; substitute a for b in $str
and:
$str ~= s/a/b/; substitute a for b in $_ and append result to $str
But I guess that's no worse than:
$x-=10;
and
$x=-10;
which doesn't seem to be a problem for people in Perl 5.
Damian
Joseph F. Ryan
> Adam D. Lopresto wrote:
>
>> Really what I've been wishing for was an operator (or whatever) to
>> let me do an
>> s// without changing the variable.
>
>
> I would hope/expect that that's what the subroutine form of C<s> would
> do.
>
> That is, it takes a string, a pattern, and a replacement string,
> and returns a new string with substitution performed (without affecting
> the original string):
>
> print 'He said "$( s($statement,/\.$/,"") )", but we didn't believe
> him.';
That seems a bit obfuscated; is there any chance the subroutine form could
be called C<subst> or C<substitute>?
Damian Conway
> Really what I've been wishing for was an operator (or whatever) to let me do an
> s// without changing the variable.
I would hope/expect that that's what the subroutine form of C<s> would do.
That is, it takes a string, a pattern, and a replacement string,
and returns a new string with substitution performed (without affecting
the original string):
print 'He said "$( s($statement,/\.$/,"") )", but we didn't believe him.';
Damian
Deborah Ariel Pickett
> (b) the symmetry of:
> Logical: && || !!
> Bitwise: .& .| .!
> Superpositional: & | !
> is important...mnemonically, DWIMically, and aesthetically.
When I read that this morning I worried - as I do when I read most things
from Damian (but that's a different story). I think it came down to
what I think was a violation of the Principle of Least Surprise, in the
form of good Huffman coding of operators.
The proposed superpositional operators (& | !) are shorter than the
proposed logical operators (&& || !!). Normally the shorter
operator (or, in English, word) is the more common one. Is
superposition really more common than boolean combination?
I sort of toyed with the idea that maybe it should be the logical
operators which are the short ones (& | !) and the rarer superposition
ones that require you to press another key (&& || !!). This had the
added bonus of leaving logical-not the way we all love, and it probably
had some nostalgia element for both B (*) programmers still out there
with respect to & and |.
But now I see some examples and I'm not so sure. The size of the
doubled-up operators seem to visually separate the arguments to the
logical operations better. This is especially so if the precedence for
these operators fall the way people have been saying.
Which looks better?
if ($a == 1|2|3 || $b eq "x"|"y"|"z")
or
if ($a == 1||2||3 | $b eq "x"||"y"||"z")
?
Opinions welcomed, but tell us all what typeface you're using.
Besides, maybe superposition is going to turn out to be a very common
thing in Perl after all. I can guess Damian's response to that.
I think I've already decided that I prefer it the way it is (for recent
values of "is"). I just need some kind soul to pat me on the head and
tell me it's OK.
(Please excuse the Monash staff member, it's been a difficult week.)
(*) The precursor to C, not the highly formal OO language.
--
Debbie Pickett http://www.csse.monash.edu.au/~debbiep deb...@csse.monash.edu.au
My parents went to a world without bilateral symmetry and all they brought back
was this lousy F-shirt.
Adam D. Lopresto
s// without changing the variable.
print 'He said "'_($statement ~ s/\.$//)_'," but we didn't believe him.';
I'm not sure exactly what the semantics would be, but somehow =~ without the =
seems appealing...it's always seemed annoying to have to make a new variable
for things like that, instead of being able to do it in place. But then,
perhaps that isn't justification for an entire operator so much as
$statement.replace/\.$//
or something....
Mental note: no more postings right before bed.
--
Adam Lopresto (ad...@cec.wustl.edu)
http://cec.wustl.edu/~adam/
Falls don't kill people. It's the deceleration trauma.
Fearcadi
>I certainly wouldn't mind seeing it return to that role, now that
>it's not needed elsewhere. And, of course, that would actually be:
>
> $x ~ $y string concatentation
> $x ~= $y string append
> ~$x stringification
> $str =~ s/a/b/; substitute a for b in $str
>
> $x-=10;
> ...
> $x=-10;
> which doesn't seem to be a problem for people in Perl 5.
>
So now
$x = ~$y
is not the same as
$x =~ $y
but
$x =- $y
is same as
$x = -$y
Dont we have for consistency ( or may be I have a wrong idea of consistency )
to prohibit ( or rize warning ) when "=-" ( or "=+", "=/" and so on ) appear .
besides it will make "=" an operatorial prefix ( which beutifully makes sence
in "=~" operator) . And maybe in future we can find uses for "=|" , "=!" , ...
..
And to start with, we can make them legitimate operators to be overloaded .
Maybe , my question really is , how perl will behave if I will do
sub operator:=+ (str $x, str $y) { system( "$x | $y" ) } ;
so this is more question of qrammar ?
?
arcadi .
Larry Wall
: Maybe , my question really is , how perl will behave if I will do
:
: sub operator:=+ (str $x, str $y) { system( "$x | $y" ) } ;
:
: so this is more question of qrammar ?
The general rule in most lexers has always been that it grabs the
longest token it can recognize. So adding that definition would
change the meaning of
$a=+$b;
unless the lexer has a built-in rule that allows it to recognize
operators that haven't been defined yet. It's tempting to
require whitespace after certain classes of operators, but it
would certainly enrage a segment of the population.
On the other hand, the current rule for recognizing the *end* of a
name in the style of operator:=+ is to go till the next whitespace,
on the assumption that we'll never have (shudder) whitespace operators.
But that doesn't mean we have to require whitespace after every
operator. Putting the whitespace merely guarantees that it will
never be interpreted as a longer operator.
I think putting whitespace around any operator containing "=" is a
really good idea just on general principle. But I'm not willing to
inflict my principles on people mandatorily unless there's a really
good reason (as I think there is with mandatory curlies).
Larry
Larry Wall
: Which looks better?
: if ($a == 1|2|3 || $b eq "x"|"y"|"z")
: or
: if ($a == 1||2||3 | $b eq "x"||"y"||"z")
: ?
I think disjunctions of data values should be | and disjunctions of expressions
should be ||, so that the "bigger" concept has the bigger operator.
: Besides, maybe superposition is going to turn out to be a very common
: thing in Perl after all.
I think we'll see an awful lot of them that people won't even think of as
superpositions, for instance:
when 1 | 2 | 3
You know, we could go so far as to say that in regexen, | is unordered
and || is ordered. Then we could optimize | to work via DFA or in
parallel (for whatever definitions of parallel you want) . But that'd
be a rather significant cultural change...
: I think I've already decided that I prefer it the way it is (for recent
: values of "is"). I just need some kind soul to pat me on the head and
: tell me it's OK.
It's really OK. The head pat is more problematic--I seem to flip my
hemispherical sign bits one at a time, never both at once for the
same trip. Perhaps Damian could give you a head pat by proxy next
time you run into each other.
Larry
Michael Lazzaro
Brent Dax wrote:
> Can the new nefarious use be concat? Pretty please?
On Wednesday, October 23, 2002, at 07:46 PM, Damian Conway wrote:
> I guess the only concern is the potential for nasty surprises between:
> $str =~ s/a/b/; substitute a for b in $str
> and:
> $str ~= s/a/b/; substitute a for b in $_ and append result to $str
On behalf of the Dumb People, I object. :-)... When I'm training
newcomers to Perl, one of the hardest things for them to get is the =~
operator doing a regex. Regexen aren't a base part of most languages
that beginning programmers use, but it's an integral part of Perl.
Noone ever guesses that =~ means "matching": it looks like an
assignment, which it sometimes is, and sometimes isn't, etc. It takes
a lot of explaining, and even then people have often written ~= when
they mean =~, and stared at it for a half hour not knowing why it
didn't work.
So I think the =~ vs ~= would be very, very confusing to people, just
because =~ is already very confusing to start with, which, in turn,
implies we can't use ~ for concat.
If anything, I'd almost suggest the other way around, such that ~ means
matching and ~= means matching assignment:
$str1 ~ $str2 # $str1 =~ m/$str2/
$str ~ /foo/ # $str1 =~ m/foo/
$str2 = ($str ~ /foo/bar/); # perform subst, assign result to $str2
$str ~= /foo/bar/; # perform subst, assign result to $str
.... which sortof goes better with the new 'magic matching' usage of =~,
and I could make some vague argument for matching +=, etc. IF we want
to muck with it at all.
MikeL
Jonathan Scott Duff
> Noone ever guesses that =~ means "matching"
That's because it doesn't. =~ means something more akin to "apply"
but it's only valid for the three m//, s///, tr/// ops. That'll
change in perl 6 though :-)
> If anything, I'd almost suggest the other way around, such that ~ means
> matching and ~= means matching assignment:
>
> $str1 ~ $str2 # $str1 =~ m/$str2/
> $str ~ /foo/ # $str1 =~ m/foo/
> $str2 = ($str ~ /foo/bar/); # perform subst, assign result to $str2
> $str ~= /foo/bar/; # perform subst, assign result to $str
I like it even though the naked ~ always makes me think of awk.
Larry Wall
: $str1 ~ $str2 # $str1 =~ m/$str2/
That would be a smart match, not m/$str2/.
: $str ~ /foo/ # $str1 =~ m/foo/
That would work.
: $str2 = ($str ~ /foo/bar/); # perform subst, assign result to $str2
:
: $str ~= /foo/bar/; # perform subst, assign result to $str
That can't work without the "s". The lexer can't tell if "bar" is a string
or an operator.
But the ~= is a cute trick. Not sure if it's more than that though.
Gotta worry about s/// in a boolean context, for instance. And the
current idiom
($str2 = $str1) =~ s/foo/bar;
is not much longer than yours, though your parens are, I think, optional,
while mine aren't.
But we also have to balance it against the desirability of using ~ for
concatenation. Requiring whitespace around _ is a bit of a rationalization
after the fact, and ~ escapes that problem in most cases.
Plus, smart matching is such a heavyweight, notionally speaking,
that it really deserves a larger operator. Since there's no such
thing as a "logical concat", we might get away with using ~~, and
then people wouldn't have to wonder whether it was ~= or =~.
Or we could make it ===. That would pretty much rule out having the
corresponding assignment operator though...
Or we could leave it =~ for old times sake, and make people learn
the difference from ~=.
Or go with something new:
$a :~ $b
$a =~= $b
$a =? $b
$a <?> $b
$a <~> $b
$a >< $b
$a ::: $b
$a match $b
$a like $b
$a vs $b
$a v $b
If it is, in fact, a topicalizer, then the Japanese would very
naturally parse a postpositional particle:
$a wa $b
Or we could go with Valspeak:
$a is like $b and stuff
At the moment I like "like" the best, actually...
Larry
Larry Wall
: Adam D. Lopresto wrote:
:
: > Really what I've been wishing for was an operator (or whatever) to let me do an
: > s// without changing the variable.
:
: I would hope/expect that that's what the subroutine form of C<s> would do.
The problem with defining that as the primitive behavior is that some substitutions
are very much faster in place, and it would be difficult to capture.
: That is, it takes a string, a pattern, and a replacement string,
: and returns a new string with substitution performed (without affecting
: the original string):
:
: print 'He said "$( s($statement,/\.$/,"") )", but we didn't believe him.';
It's possible the syntax for substitution should be wrapped around the syntax
for matching, whatever that turns out to be.
replace($statement =~ /\.$/, "")
replace($statement like /\.$/, "")
or even:
replace($statement like /\.$/, with => "")
We shouldn't limit our notions to strings:
replace(@array like 1|2|3, $& + 1);
or if @array is the topic
replace(1|2|3, $& + 1)
It's not yet clear where in-place vs en-passant fits in here.
Perhaps there's two different functions, spliting replace into
"inplace" and "outplace". :-)
I'm sure there are better words with the right connotations though.
Larry
Angel Faus
>
> At the moment I like "like" the best, actually...
>
"like" is beautiful for old-style regex matching, but I find it
confusing for the new smart abilities:
$var like Class:Foo # $var is instance of Class:Foo
$item like %hash # %hash{$item} is true
$digit like (0..10) # $digit is in 0..10 range
@array1 like @array2 # array intersection
$num like &f # f($num) is true
All this ones fit more with the concept of "mystical analogy" hinted
by =~ than with the plain similarity that one would expect from
"like"
Oh, and =~ looks much more intimidating, which is good, given its..
err.. power.
-angel
Chris Dutton
>
> $a is like $b and stuff
>
> At the moment I like "like" the best, actually...
Hmmm... I could actually see "like" in a more active role. Along the
lines of:
my str $string;
my $other_string is like $string;
Analogous to saying:
my str $other_string
Except that it would get new type information if the type of $string is
changed at some point. Might be useful for generic classes.
class LimitedStack {
attr @.array;
my $init;
method new($first, *@others are like $first) {
$init = $first;
@.array.push($first, *@others);
}
method push(*@items are like $init) { ... }
method pop { ... }
}
Also, this brings to mind the one thing I actually remember about
Sather, and as long as we're discussing operators...
Will we have similar to Sather's "::="? That was essentially the
"statically type this variable at run-time based on the type of it's
initial value" operator.
Luke Palmer
> Date: Fri, 25 Oct 2002 00:54:09 +0200
>
> All this ones fit more with the concept of "mystical analogy" hinted
> by =~ than with the plain similarity that one would expect from
> "like"
True. Can't say I like, um, like.
> Oh, and =~ looks much more intimidating, which is good, given its..
> err.. power.
I fancy ~ or ~~ at the moment. To me, =~ implies some sort of
assignment, seeing as there's a single equal sign in it. =~= looks
more like a comparison, but it's too ugly-prolog-like.
Indeed, I like the I<concept> of out-of-place substitutions, and using
~= or ~~= (the duck) for in-place. Though, as pointed out, the
in-place efficiency of such a thing would be hard to detect.
But--that's for the practical perliticians to work out :)
Luke
Smylers
> On 20 Oct 2002, Smylers wrote:
>
> : Seems like not too long ago we were short of punctuation symbols,
> : and now you've got a spare one lying around.
>
> Pity there's no extra brackets lying around without going to
> Unicode...
Well if C<~> were made the hyper prefix (squiggly line suggesting
motion or 'and so on' through a set of things?) that would free up C<^>.
And the caret could be a bracket if you rotate your head to the right:
^
1
2
3
v
Might have to outlaw ending identifiers with "v" though ...
Now that C<.> is used in bitwise operators, does it make sense to use it
in bitwise shifts too:
$a .< $b
$a .> $b
That would almost free up C< << > and C< >> > for being brackets of some
sort, but only 'almost' here-docs use the former.
Smylers
David Wheeler
> On the other hand, the current rule for recognizing the *end* of a
> name in the style of operator:=+ is to go till the next whitespace,
> on the assumption that we'll never have (shudder) whitespace operators.
Oooh, I nominate whitespace to be the concatenation operator!
my $foo = $bar $bat;
;-)
David
--
David Wheeler AIM: dwTheory
da...@wheeler.net ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: The...@jabber.org
Michael Lazzaro
On Thursday, October 24, 2002, at 11:22 AM, Larry Wall wrote:
> But we also have to balance it against the desirability of using ~ for
> concatenation. Requiring whitespace around _ is a bit of a
> rationalization
> after the fact, and ~ escapes that problem in most cases.
So (w/out whitespaces):
$a~$b # (1) concat
$a~=$b # (2) $a = $a ~ $b
$a=~$b # (3) $a = the stringification of $b (using unary ~)
and something similar to the following
$a ~~ $b # maybe perl5 =~, the "logical" look
$a <?> $b # maybe perl5 =~, the "comparator" look
$a like $b # maybe perl5 =~, the "english" look
Hmm, something like that could work.
> From: Angel Faus <af...@corp.vlex.com>
> Oh, and =~ looks much more intimidating, which is good, given its..
> err.. power.
Well, I was sort of trying to _avoid_ the intimidating part, because
Perl is already intimidating, or so we keep hearing. :-) :-) Stop
being intimidating!
But in any case (if ~ means concat) I don't think we could sensibly
leave =~ as '=~'. I would think we'd want unary ~ to work after '=',
which would nix it right there, unless we want required whitespace
again. Plus, it's ugly and its parents dress it funny.
MikeL
Larry Wall
: Also, this brings to mind the one thing I actually remember about
:
: Will we have similar to Sather's "::="? That was essentially the
: "statically type this variable at run-time based on the type of it's
: initial value" operator.
I was thinking ::= would be a := variant that binds at compile time.
A "latchy" operator seems a bit weird to me. I'm not sure what it
buys you that you couldn't get more straightforwardly through eval.
It's a bit like the /o modifier on regexes. If you don't know the
type at compile time, it's unlikely that you'll want to nail it down
to the first type that comes along when other types might also want
to use the same code generically.
Larry
Trey Harris
As long as you're trying to figure out how to shoehorn in the last few
available punctuation symbols, and thinking about if there are any
bracketers left, I wondered if there was a chance of a chunking operator
for literate programming? So you can do something like this, if <<<>>>
were the operator:
=doc code
We loop through the array, operating on each item:
=cut
for @list -> $item is rw { # is 'is rw' assumed with for? I forget...
<<<operation>>>
}
=doc code
The operation performed is incrementing each item by one:
=chunk operation
$item++;
=cut
Trey
Austin Hastings
a = b+++++c;
In Perl, we can have:
$a = $b $c;
(Parseable as $a = $b operator:spacespace operator:tab
operator:spacespace $c;)
Oh frabjous day!
=Austin
__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/
David Wheeler
> In 'C', we have:
>
> a = b+++++c;
>
> In Perl, we can have:
>
> $a = $b $c;
>
> (Parseable as $a = $b operator:spacespace operator:tab
> operator:spacespace $c;)
>
> Oh frabjous day!
Good Lord, you're sicker than I am!
:-D
Jonathan Shapiro
converts
operator:tab
to
operator:spacespace operator:spacespace
Anyone for makefiles?
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
Larry Wall
: 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};
Problem with that...the replacement argument has to be lazy, and currently
the RHS of an assignment is actually evaluated before the left. You'd
really need something more like
$str =~ /\d/ = { 0 }
However, I think readability suffers without a hint on the front what
you're trying to do. So I'd be more inclined to say that the general
syntax is really more in the spirit of a conditional:
where $str =~ /\d/ { 0 }
The difference between inplace and copying is then really the disposition
of the closure:
where $str =~ /\d/, replace => { 0 }
where $str =~ /\d/, return => { 0 }
But that's clunky. If replacement is the norm, then returning a copy is just
where $str =~ /\d/ { 0 }
where $str.dup =~ /\d/ { 0 }
The topicalized forms would then be:
where /\d/ { 0 }
where .dup =~ /\d/ { 0 }
Except that still doesn't tell it whether to return a boolean or a string...
Of course, most of the time you want to replace with a string, and
where /\d/ { "0" }
is still a lot clunkier than
s/\d/0/;
Maybe we end up with that form and a Ruby-esque
s(/\d/) { "0" }
in the general case. Or it could go in the parens. Hey, maybe that's
a good spot for an arrow:
s(/\d/ -> { "0" })
In any event, we still haven't really solved the want-a-string vs
the want-a-boolean problem. Maybe it's just context:
if s(/\d/ -> { "0" }) {...} # boolean context, in-place
s(/\d/ -> { "0" }); # void context, in-place
print s(/\d/ -> { "0" }) # string context, return string
$result = ~s(/\d/ -> { "0" }) # string context, return string
$result = ?s(/\d/ -> { "0" }) # boolean context, return string
$result = s(/\d/ -> { "0" }) # untyped context, return what?
But I suspect that's too much weight to put on the context system. It
doesn't really solve the readability problem, especially when we get more
that one {...} in a row.
By all accounts, a s/// is an odd thing to put in a smart match
anyway. You can't have a superposition of things with side effects,
for instance:
$str =~ s/a/b/ | s/b/c/
Though doubtless Damian can think of something indeterminate to make
it mean. :-)
The in-place really feels more like you want a method
$str.s/a/b/
@foo.s(1|2|3, {0})
or maybe
$str.subst/a/b/
@foo.subst(1|2|3, {0})
Maybe the return value form is also a method:
$result = $str.where/a/b/
@result = @foo.where(1|2|3 -> {0})
In typical topical string usage, that leaves us with
if .subst/a/b/ {...}
$result = .where/a/b/
That's quite livable, though the second is a bit odd, English-wise.
We could even keep around
s/a/b/
as a shorthand for .subst/a/b/. And maybe even add
w/a/b/
as a synonym for .where/a/b/.
If so, possibly we don't have .subst/a/b/, but just .subst(/a/ -> { "b" })
for the general form. But string-like method args are certainly a possibility
in general, provided we can keep the declarations in order. But if not,
there's a bad ambiguity between
.subst/a/b/
and things like
.size/2
: (hyper, however it's spelt, will have some way for the RHS to reference the
: LHS, won't it?)
Haven't specified one. @array ^= 0 is supposed to do the right thing already,
and doesn't require the right side to know anything about the left side.
Larry
Martin D Kealey
> 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.
Michael Lazzaro
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 or xor
.& .| .! - 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 defined undef
length exists delete
sqrt log sin cos tan
lc lcfirst uc ucfirst
int ord oct hex (bin?)
(...etc...)
MikeL
Larry Wall
: Since it's been a full month since the start of the monster "operator
: 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.
: sqrt log sin cos tan
: lc lcfirst uc ucfirst
: int ord oct hex (bin?)
:
: (...etc...)
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...
Larry
Dave Mitchell
> && || !! // - boolean operations
> &&= ||= !!= //=
> and or xor
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.
Austin Hastings
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
=== message truncated ===
Michael Lazzaro
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
Austin Hastings
--- Michael Lazzaro <mlaz...@cognitivity.com> 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<my Pet $lunch;> 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 ...
fido dog collie
fluffy cat siamese
};
> 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
Michael Lazzaro
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
Nicholas Clark
> 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/
Miko O'Sullivan
> : ? - 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
Paul Johnson
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 - pa...@pjcj.net
http://www.pjcj.net
Brent Dax
# 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 <bren...@cpan.org>
@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)
Damian Conway
> 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"
}
Hmmmm. Maybe C<none> is starting to grow on me. Bwah-ha-ha-ha-hah! >;-)
Damian
Larry Wall
: 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
Larry Wall
: 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<bar> 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 define:
postfix:! # factorial
infix:! # xor superposition
prefix:! # logical negation
The problem is now that you can't say
$x .! # still factorial!
if you want to put space before the postfix !, because we comandeered the
dot for bitops. Hmm. Maybe that was a mistake. Something to ponder.
I expect we can't just rely on bracket properties in Unicode for understanding
how to parse operators though, or we can't write things like:
term:'' # single quoted string.
Either we need a placeholder, or something that says to treat matched chars
as bracket chars. The placeholder is more general, particularly if it
specifies the grammar rule to parse the inside:
term:'<singletext>'
term:(<expr>)
Note also that we do have to distinguish term from prefix, since they leave
the lexer in a different state of expectation afterwards.
So we end up not with:
postfix:<>
infix:<
term:<>
but rather
postfix:<lt><mumble><gt>
infix:<lt>
term:<lt><expr><gt>
Now you can finally have your
infix:<ws>
operator. :-)
It will, of course, totally break the lexer. Your choice, though.
Larry
Chris Dutton
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.
Larry Wall
: So many operators...
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
Michael Lazzaro
> So many operators...
Well, this seems a good as time as any to jump in with what's been
sticking in my brain for a while now. Last June, Simon C. wrote a
little philosophical thing, "Half measures all around", which generated
the appropriate amount of good discussion. I want to try and make a
case that's sortof tangential to that, but not, at the same time.
Here's my own argument for using "like/unlike", and "none", and a bunch
of other english-sounding things we haven't even talked about yet.
My general background is in tutoring/mentoring/educating/evangelizing
"new" programmers, where "new" either means new to programming, or new
to Perl5, or both. That's my little niche -- taking newbies, and
shoving them up the curve until they know the ins and outs. Pretty
successful at it too, I think. I mention this only because it seems to
be different from the experience of much of perl6-lang ... most of the
people here seem to be more of the "expert" level, people who you call
because they know Everything Perl, Always. :-) I'm typically more
focused on the beginning-level people.
Premise: So far, we've already gotten Perl6 to be much more powerful
than Perl5, and cleaned up a few of the more troublesome perl5
inconsistencies, but I don't think we've put much of a dent in the
"readability" complaints that non-perlers often voice (and we all know
I'm being generous in my phrasing, there.) I think we need to care
about these concerns a _lot_ more than we have in the past, simply
because of the cynical but obvious linkages:
1) I want to use Perl6, because I am confident that I can program
things faster in Perl6 than in any other mainstream language.
2) I only want "good" Perl6 programmers, so I don't give a, um, 'darn'
how much of the random population uses Perl6 in general, BUT...
3) The general population won't use it unless they can easily
understand it through self-study, and/or have been exposed
to it in an educational setting.
4) Joe Manager of Company X won't use it unless he can find
lots of programmers in the general population that know it.
5) If none of the Joe Managers in the other companies use it,
suddenly it puts a lot of pressure on me to explain why *we're*
using it, instead of, say, Java or C#. "It's better"
doesn't really fly, because the company's non-technical
staff judges "better" based primarily on the number of
magazine articles that mention the language.
6) Suddenly, my staff using Perl6 becomes a political issue, not a
technology one. I fight the battles, eventually quitting
the industry in disgust and moving to the California desert
where I put up "no trespassing" signs, dig a series of
inexplicable washing-machine sized holes, and wait for
the impending collapse of human civilization.
OK, that's why we care what the world thinks. Back on topic: so far
we've got conciseness, and a feature set that's essentially the
best-practices compilation of modern, successful programming concepts.
Pretty darn nice.
But understandable, we don't have yet.
Understandability in the large, certainly, is a matter of being able to
express common and/or complicated concepts in a concise enough way to
make the "big picture" of the program visible. So even though Perl6 is
full of nasty constructs such as '^.|=' and similar, I would argue that
(1) things quite that bad will be reasonably sparse in real programs,
and (2) they comprise so much functionality in such a little package
that the overall "flow" of what's happening in an algorithm is much more
understandable. Hence we have all hyperoperators, for example -- just
too much utility there *not* to do it.
But our version of "understandable" still means a steep, steep learning
curve. We need to soften that a bit more for the common cases. My own
solution would be, in part, that we offer english-word aliases like
"like", etc., even if they're only meant as training-wheel versions of
the more linenoisy things, wherever we can. So people can be trained on
the words, and graduate to the "professional" constructs as they become
more comfortable.
My bigger solution would be to reserve a lot more english-sounding
barewords, in all forms, towards the goal of making well-understood
concepts more obvious to newcomers. That's why I've been pushing for
architecturally unnecessary things like using "on" for events/callbacks/assertions:
my $v on get { ... }
on set { ... };
....or using constructs like 'as' and 'from' to do very smart, but very
in-your-face-obvious casting/transformations between types/classes,
instead of relying on more ambiguous constructs:
class MyClass {
from OtherClass { ... } # 'alternate' constructors
from int { ... }
as int { ... } # 'typecasting' multimethods
as str { ... }
as OtherClass { ... }
}
my MyClass $obj = MyClass.new;
print $obj; # as string
print $obj as int; # as int
....or even to just have the inclusion of more non-property properties
and other keywords, because they DWIM:
class MyClass is singleton;
cmethod class_method { ... }
method instance_method { ... }
my hex $i; # with built-in (de)serializers
.... even though there are other, more logically "correct" ways of
accomplishing the same things. [*1] Sure, we don't *need* those words,
but they're only a few extra chars, and they express rather fundamental
concepts in one-word English, instead of relying on knowledge of
canonical and/or punctuational constructs to build the same. Does it
complicate the grammar? Yes, a little. But maybe for some things,
TMTOWTDI isn't the right answer. Maybe some concepts are so universal
that there _should_ be a "best" way to do it, and a word that means it.
So this isn't a rant, exactly (read the preface of the POOC [*2] to see
just how much I like perl6 already) but I do think we need to
occasionally remind ourselves that the people on this list do *not*
represent the skill levels of the general population, and we *need* the
support of the general population. If we have even a slight bit of
trouble with something, heaven help us when we try to explain it to the
rest of the planet.
When I've been writing my dribbles of draft documentation, I've been
going to great lengths to explain concepts using as few big words as
possible, and it's really, really hard. I think we can make it a little
easier by having the language itself use as many of the little words as
possible, and explaining them as english-esque constructs instead of
programmerspeak. So lets have _lots_ of operators, and _lots_ of
two-to-four-letter barewords, so long as they each do something Big, or
something Universal. And let's locale-ize them, so that
non-english-speakers can use 'umu' to mean 'bool', etc. Hey, why the
heck not?
OK, philosophical ramblings over. Thanks for listening. :-)
MikeL
[*1] Am I emotionally attached to any of my own suggestions? No, not
really. I just want to document and use the end result; I don't care
how we get there, or even quite where "there" eventually is. If you've
been following this list, you know that 90% of the postings --even
Larry's stuff-- are just stream-of-conciousness things that are
sometimes scary, but are just thoughts, so nobody should freak out
because of anything they see here, unless and until it's Final.
Damian Conway
> Which looks better?
> if ($a == 1|2|3 || $b eq "x"|"y"|"z")
> or
> if ($a == 1||2||3 | $b eq "x"||"y"||"z"
> ?
No question thatthe former works better. Lower precedence operators govern
larger chunks, and so should themselves be larger (i.e. more easily detected).
> I just need some kind soul to pat me on the head and
> tell me it's OK.
<pat> <pat> ;-)
> (Please excuse the Monash staff member, it's been a difficult week.)
For ex-Monash staff members too. :-(
Damian
Simon Cozens
> But our version of "understandable" still means a steep, steep learning
> curve.
It's worse than that; for practitioners of many languages, the learning
curve has a 180 degree turn.
Quick: what are the bitwise operators in Java, JavaScript, C, C++, C#,
Perl 5, PHP, Ruby, and Perl 6? Which of these languages do we want to
draw programmers from?
Someone will now argue that bitwise operators aren't used very often anyway.
Great, so we make a change that bites (NPI) people when they least expect
it; that makes it all OK.
--
BASH is great, it dumps core and has clear documentation. -Ari Suntioinen
Philippe 'Book' Bruhat
> So lets have _lots_ of operators, and _lots_ of two-to-four-letter
> barewords, so long as they each do something Big, or something
> Universal. And let's locale-ize them, so that non-english-speakers can
> use 'umu' to mean 'bool', etc. Hey, why the heck not?
Why not? Here is my opinion about localized programming languages.
As a non-native English speaker, I like it very much that I *don't* have
the possibility to write:
afficher pour @tableau; # note I used functions that map
mon @uaelbat = retourner @tableau; # to single words in French ;-)
And I suspect my non-native French speaker readers like it very much too.
I suppose it's very doable to have a FrenchPerl6 editor/parser/whatever
that makes most of this transparent, but the thing I like the most about
programming languages it that their are foreign languages.
And since most of them are based on English, they are just twice as
foreign to me. So when I program, I can concentrate on what the syntax of
the programming langage accepts, rather than on the sentences I could
write if I were using a subset of French.
And imagine the pain for all those programmer that do not speak very well
their own mother tongue... Should I use "effacer", "efacer", "éfasser"
when I want to remove a file? With programming languages as there are
today, I just have to learn a new word (unlink), and this won't mess my
already messy understanding of my own language (pity the one who will read
the comments and documentation, though).
I admit that knowing a little English can be helpful to guess a function
name here and there, though. ;-)
Also, remember Microsoft moved back specifically on that topic with the
Excel and Word macro-language some years ago.
Naturally, this has nothing to do with naming your variables as you like
(even Unicode and stuff); variables are another matter entirely.
Don't misunderstand me, I love the fact that Perl works like a natural
language. It's just that I also understand the fact that it's its own
natural (English-looking) language, and not a subset of English.
-- BooK
PS: I have troubles explaining this view in French as well; please forgive
me if I didn't make much sense in English either.
--
Philippe "BooK" Bruhat
When you run from your problem, you make it that much harder for good
fortune to catch you, as well. (Moral from Groo The Wanderer #14 (Epic))
Piers Cawley
> mlaz...@cognitivity.com (Michael Lazzaro) writes:
>> But our version of "understandable" still means a steep, steep learning
>> curve.
>
> It's worse than that; for practitioners of many languages, the learning
> curve has a 180 degree turn.
>
> Quick: what are the bitwise operators in Java, JavaScript, C, C++,
> C#, Perl 5, PHP, Ruby, and Perl 6? Which of these languages do we
> want to draw programmers from?
>
> Someone will now argue that bitwise operators aren't used very often
> anyway. Great, so we make a change that bites (NPI) people when
> they least expect it; that makes it all OK.
It rather depends on how common the Superposition operators turn out
to be doesn't it? If you're used to seeing | used to construct a
superposition then you're not quite as likely to go trying to use it
in a bitwise context, but if superpositions turn out not to be a
common idiom then you're more likely to get caught out.
Me? I think once we have convenient quantum operators, we're going to
start using them all over the place, but it could just be that I'm
weird.
--
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?
Simon Cozens
> It rather depends on how common the Superposition operators turn out
> to be doesn't it?
No. No, it doesn't.
--
<ZenHam> heh, yeah, but Aretha could be reading out /etc/services and
kick just so much ass :)
Nicholas Clark
> On Fri, Oct 25, 2002 at 06:28:28PM -0400, Miko O'Sullivan wrote:
> > From: "Larry Wall" <la...@wall.org>
> > > : ? - 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
> The negate operators we have already:
>
> perl -e '$x = "0"; print !$x'
> perl -e '$x = "10.000"; print -$x'
Here is something that maybe you'd forgotten:
$ perl -lwe '$x = "Good"; print -$x'
-Good
$ perl -lwe '$x = "-Good"; print -$x'
+Good
$ perl -lwe '$x = -"Good"; print -$x'
+Good
$ perl -lwe '$x = "+Good"; print -$x'
-Good
Unary plus is actually irrelevant:
$ perl -lwe '$x = +"Good"; print -$x'
-Good
Nicholas Clark
--
Brainfuck better than perl? http://www.perl.org/advocacy/spoofathon/
Nicholas Clark
> Brent Dax wrote:
> >Which would create a superposition of all strings besides the given one,
> >right? (Oh crap, I think I gave Damian an idea... :^) )
> Hmmmm. Maybe C<none> is starting to grow on me. Bwah-ha-ha-ha-hah! >;-)
I'm worried. *I* thought Damian said that he was on (well earned) sabattical
for 3 months, from the end of YAPC::Europe. That was (roughly) 1 month ago.
So has he been taking his 3 months simultaneously in parallel universes
thanks to some utterly diabolical invention? :-)
I fear we don't want to know.
Nicholas Clark
--
Befunge better than perl? http://www.perl.org/advocacy/spoofathon/
Damian Conway
> Now I'm wondering whether these should be split into:
>
> +& +| +! - bitwise operations on int
> +&= +|= +!=
>
> ~& ~| ~! - bitwise operations on str
> ~&= ~|= ~!=
I think this is UME (Unnecessary Multiplication of Entities), especially
given:
> +$x .| +$y
> ~$x .| ~$y
> Then we could allow
>
> @a ^.~|= @b; # hyper bitwise string or-equals
Eek! Now, where did I put those dried frog pills???
> 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...
I suspect disjunctive superpositions will get a great deal
of use as sets, and so the ability to add an element to an
existing set:
$set |= $new_element;
might be appreciated. But it's no big thing.
> I'd still love to the double angles for a qw synonym.
I was hoping we'd be able to generalize << from the heredoc introducer to
the file slurp operator. But I can certainly see the attraction of:
use enum <<d'oh ray me far solar tea>>;
;-)
> : (heredocs) - (exact format unknown)
I have a paper (coming) on that.
Damian