Thanks for taking the time to write this out.
On Thu, 26 Sep 2002, John Williams wrote:
> perl6 operator precedence
>
>leftterms and list operators (leftward) [] {} () quotes
>left. and unary .
>nonassoc++ --
>leftis but
On Thu, 26 Sep 2002, Sean O'Rourke wrote:
: Thanks for taking the time to write this out.
:
: On Thu, 26 Sep 2002, John Williams wrote:
: > perl6 operator precedence
: >
: >leftterms and list operators (leftward) [] {} () quotes
: >left. and unary .
: >
On Thu, 26 Sep 2002, John Williams wrote:
: I'm trying to write a revised operator precedence table for perl6,
: 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 : (ad
On Tue, 8 Oct 2002, Larry Wall wrote:
: : perl6 operator precedence
: :
: :leftterms and list operators (leftward) [] {} () quotes
: :left. and unary .
:
: Unary . can't be left associative. Perhaps unary . is nonassoc like ++.
Actually, unary . has to b
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<..>
On Wed, 9 Oct 2002, John Williams wrote:
: 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<..>.
Larry Wall writes:
> 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 th
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
On Fri, 11 Oct 2002, Jonathan Scott Duff wrote:
: 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
[EMAIL PROTECTED] (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
On 11 Oct 2002, Simon Cozens wrote:
: [EMAIL PROTECTED] (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
[EMAIL PROTECTED] (Larry Wall) writes:
> 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
At 3:55 PM -0700 10/11/02, Larry Wall wrote:
>On 11 Oct 2002, Simon Cozens wrote:
>: [EMAIL PROTECTED] (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 ca
On Friday, Oct 11, 2002, at 23:21 Asia/Tokyo, 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
>
> $x & $ybitand($x, $y)
> $x | $ybitor($x, $y)
Objection, yo
On Fri, 11 Oct 2002, Dan Sugalski wrote:
: 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-qui
in
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 loop should
>terminate on the shorter or the longer stream. We could say that |
>t
in
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
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) t
On Sat, 12 Oct 2002, Dan Kogai wrote:
: 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
> Date: Fri, 11 Oct 2002 12:16:00 -0700 (PDT)
> From: Larry Wall <[EMAIL PROTECTED]>
>
> I'm wondering whether the single ones could indicate parallel streams.
> We had the difficulty of specifying whether the C loop should
> terminate on the shorter or the longer stream. We could say that |
> t
On Sun, 13 Oct 2002, fearcadi wrote:
: in
: 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 loop should
: >terminate on the shor
On Sun, 13 Oct 2002, Aaron Crane wrote:
: 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 equivale
>
>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);
>}
>
but then probably we should also have
@cases = @cases ^| @newcases; is same as ( @cases ^|= @newcas
Larry Wall wrote:
> 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 wit
: > 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
I think I like that. Except now we'll get things like:
@x ^~|= @y;
Hmm
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 peop
On 20 Oct 2002, Smylers wrote:
: 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 inconsisten
> Date: Wed, 23 Oct 2002 11:14:33 -0700 (PDT)
> From: Larry Wall <[EMAIL PROTECTED]>
> On top of which, Damian has expressed an interest in ! for a
> superpositional xor.
Which would behave how, exactly?
Luke
> > On top of which, Damian has expressed an interest in ! for a
> > superpositional xor.
>
> Which would behave how, exactly?
! the way people expect, I fear.
-Miko
On top of which, Damian has expressed an interest in ! for a
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:
Larry Wall:
# : > 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 a
Brent Dax wrote:
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 ac
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 would do.
That is, it takes a string, a pattern, and a replacement string,
and returns a new
Damian Conway wrote:
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 would
do.
That is, it takes a string, a pattern, and a replacement s
Damian wrote:
> (b) the symmetry of:
> Logical:&& || !!
> Bitwise:.& .| .!
> Superpositional: & | !
> is important...mnemonically, DWIMically, and aesthetically.
When I
> : 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 woul
On Thu, 17 Oct 2002, David Wheeler wrote:
: 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 )
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 e
On 16 Oct 2002, Smylers wrote:
: 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 ~? $
On Thu, 17 Oct 2002, John Williams wrote:
> > > : 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.
> > >
> >
On Thu, 17 Oct 2002, Brent Dax wrote:
: 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 )
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
On Thu, Oct 17, 2002 at 02:57:22PM -0700, Larry Wall wrote:
> 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
> !
On Thu, 17 Oct 2002, Adam D. Lopresto wrote:
: 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 lo
On Thu, 17 Oct 2002, Adam D. Lopresto wrote:
> > : 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 almos
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 tim
On Wednesday, October 16, 2002, at 04:55 PM, Smylers wrote:
How about keeping caret for xor?
$a ~^ $b # bitwise xor
$a ^^ $b # logical xor
Hm, the "seagull operator"?
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED]
On 2002-10-17 at 22:52:49, Smylers wrote:
> 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 ter
On Thu, 17 Oct 2002, Jonathan Scott Duff wrote:
: > 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?
Mark J. Reed wrote:
> 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 m
Larry Wall wrote:
> $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
> 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).
Michael Schwern recently suggested "Monaco,
Neep or, if you can find them, Mishawaka or ProFont".
I investigated and found this
Me wrote:
> > 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 bot
Really what I've been wishing for was an operator (or whatever) to let me do an
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
Damian Conway wrote:
>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 ~= $ystring append
> ~$x stringification
> ...
> $st
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):
On Thursday, October 24, 2002, at 10:34 AM, Larry Wall wrote:
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 whitespa
> From: Angel Faus <[EMAIL PROTECTED]>
> 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 inti
Or we could go with Valspeak:
$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 th
On Thu, 24 Oct 2002, Chris Dutton wrote:
: 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
>
> 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:
$varlike Class:Foo # $var is instance of Class:Foo
$item like %hash # %hash{$item} is true
$digit like (0..10)
On Thu, 24 Oct 2002, Damian Conway wrote:
: 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 would do.
The problem with defining t
On Thu, 24 Oct 2002, fearcadi wrote:
: 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
On Thu, 24 Oct 2002, Deborah Ariel Pickett wrote:
: 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
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
Larry Wall wrote:
> 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 (squi
On Thu, 24 Oct 2002, Michael Lazzaro wrote:
:$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
:
:$st
On Thu, Oct 24, 2002 at 09:59:00AM -0700, Michael Lazzaro wrote:
> 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 almos
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!
=Austin
--- David Wheeler <[EMAIL PROTECTED]> wrote:
> On Thursday, October 24, 2002, at 10:34 AM, Larry Wall wrote:
>
>
On Thursday, October 24, 2002, at 02:52 PM, Austin Hastings wrote:
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
David
--
D
M
> To: [EMAIL PROTECTED]
> Cc: Larry Wall; fearcadi; Damian Conway; [EMAIL PROTECTED]
> Subject: Re: perl6 operator precedence table
>
>
> On Thursday, October 24, 2002, at 02:52 PM, Austin Hastings wrote:
>
> > In 'C', we have:
> >
> > a = b
On Fri, 25 Oct 2002, Martin D Kealey wrote:
: 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
:
: $
On Thu, 24 Oct 2002, Larry Wall wrote:
> It's possible the syntax for substitution should be wrapped around the syntax
> for matching, whatever that turns out to be.
That strikes me as promising...
Going back to Perl5 for a moment, we have
substr($str,$start,$len) = $newstr
why not simply ext
Deborah Pickett wrote:
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 n
Larry Wall wrote:
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. :-)
Of course. That j
This is exactly what I wanted .= for.
@array .= splice(2,0,$element); # in-place, @array = @array.splice
@new = @array.splice(2,0,$element);
$sentence .= lcfirst;
The semantics are pretty clear, then it's just up to the compiler to optimize
it for in-place. Perhaps functions could ove
On Tue, 29 Oct 2002, Damian Conway wrote:
> Or one could define a copy-the-invoke method call operator (say, C<+.>):
As a rule I prefer to see "safe" operations have short names and
"dangergous" operations with longer ones. In this context that means "copy"
gets the short name and "in place" g
On Fri, 25 Oct 2002, I wrote:
> > 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};
On Thu, 24 Oct 2002, Larry Wall
> Date: Thu, 31 Oct 2002 13:02:44 +1300 (NZDT)
> From: Martin D Kealey <[EMAIL PROTECTED]>
>
> We don't in general have a "let" on the front of assignment statements; why
> should this type of assignment be any different? (Do we want a "let" keyword?
> Personally I don't think so, but what do othe
Sorry for the one-month-old response, but this message fell between the
cracks and I was just reviewing all my old new mail
In a message dated Sun, 20 Oct 2002, Me writes:
> > Somebody fairly recently recommended some decent fixed-width
> typefaces.
> > I think it may have been MJD, but I can
Larry,
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
81 matches
Mail list logo
