fonts (was Re: perl6 operator precedence table)
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'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/ I really like the font I have on my iMac called QuickType. Unfortunately, I can't figure out where it comes from, as none of my font files have a name resembling anything like that. I need to find a utility that will identify what file a given font comes from. Trey
Re: perl6 operator precedence table
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 replied:
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 }
How about just
$str =~ /\d/ .= 0
or
$str =~ /\d/ .= { 1 + $_ . 7 }
in which using . (apply) would force a fetch of the LHS in advance of
evaluating the RHS. And for global-replace we could use the vector/hyper
notation:
$str =~ /\d/ [.=] 0
However, I think readability suffers without a hint on the front what
you're trying to do.
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 others think?)
-Martin
--
How to build a Caspian Sea oil pipeline - step one: get elected president...
Re: perl6 operator precedence table
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 others think?) I think people want it. I mean, nobody complained when it was added to the language in A5 :) Luke
Re: perl6 operator precedence table
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 override the default
method splice (...) { #general function for making a new string
method splice (...) is inplace { #overloading to optimize for in-place
but that might be going a bit too far.
I would, however, point out that other methods could
potentially have modify-in-place and a copy-and-modify
variants:
@array.splice(2,0,$element); # in-place
@new = @array.splice(2,0,$element); # on copy
$str.chomp; # in-place
$new = $str.chomp;# on copy
$str.lcfirst; # in-place
$new = $str.lcfirst; # on copy
@array.map({ %trans{$^a} }); # in-place
@new = @array.map({ %trans{$^a} }); # on copy
So we might want to look for a more general solution.
Unfortunately, one can't just generalize and use
void/non-void context to determine the correct behaviour,
since in-place matches and substitutions still need to
return their match object:
$matched = $str.replace(/foo/ - { 'bar' }); # in-place
$newstr = $str.replace(/foo/ - { 'bar' }); # on copy
One could perhaps change the verb to a participle:
@array.splice(2,0,$element); # in-place
@new = @array.spliced(2,0,$element); # on copy
$str.chomp;# in-place
$new = $str.chomped; # on copy
$str.lcfirst; # in-place
$new = $str.lcfirsted; # on copy
@array.map({ %trans{$^a} }); # in-place
@new = @array.mapped({ %trans{$^a} }); # on copy
$matched = $str.replace(/foo/ - { 'bar' }); # in-place
$newstr = $str.replaced(/foo/ - { 'bar' }); # on copy
but I doubt that would be well accepted. ;-)
Or one could define a copy-the-invoke method call operator (say, C+.):
@array.splice(2,0,$element); # in-place
@new = @array+.splice(2,0,$element); # on copy
$str.chomp;# in-place
$new = $str+.chomp;# on copy
$str.lcfirst; # in-place
$new = $str+.lcfirst; # on copy
@array.map({ %trans{$^a} }); # in-place
@new = @array+.map({ %trans{$^a} }); # on copy
$matched = $str.replace(/foo/ - { 'bar' }); # in-place
$newstr = $str+.replace(/foo/ - { 'bar' }); # on copy
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/.
Oh, I definitely think so!
And maybe even add
w/a/b/
as a synonym for .where/a/b/.
Hm. *s*ubstitute and *w*eplace. ;-)
Damian
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
I just want a plate and a fork and a bunny...
Re: perl6 operator precedence table
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 gets the longer one.
So we should define that methods where possible return new values rather
than acting in-place, but define an apply-assignment operator (say C.=) to
use when you want to act in-place. Of course, the methods can be made aware
of this so that they can optimise where appropriate.
$str .= chomp; # store result in-place
$new = $old . chomp;# return resultant value
$str .= lcfirst;# store result in-place
$new = $old . lcfirst; # return resultant value
$str .= replace( /foo/ - {'bar'} );
$new = $old . replace( /foo/ = { 'bar' } );
Unfortunately that sits badly with things that return two non-scalars
(such as splice resulting in an portion excised and a remainder) because
it means that this assignment operator doesn't return the resulting value
the way that other assignment operators do.
Also having the in-place version return something different from the copy
version would be non-obvious to neophites, but that's a problem no matter
what notation is used.
excised = array .= splice($position,$count,insertions);
vs
excised = array . slice($position,$count);
unexcised = array . splice($position,$count,insertions);
So, in
a = b .= grep {/foo/};
should a be the elements that Ido contain foo or those that Idon't?
-Martin
Re: perl6 operator precedence table
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 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
Re: perl6 operator precedence table
On Thu, 24 Oct 2002, Larry Wall wrote:
It's possible the syntax for substitution should be wrapped around the syntax
for matching, whatever that turns out to be.
That strikes me as promising...
Going back to Perl5 for a moment, we have
substr($str,$start,$len) = $newstr
why not simply extend pattern-matching in a similar way to substr, making it
an L-value, so that one gets
$str ~ /[aeiou]+/ = vowels($)
or
$str ~ /\d/ {hyper-symbol}= (0) x {size-of-LHS-array};
(hyper, however it's spelt, will have some way for the RHS to reference the
LHS, won't it?)
-Martin
--
4GL ... it's code Jim, but not as we know it.
Re: perl6 operator precedence table
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 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. 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 actually be: $x ~ $y string concatentation $x ~= $ystring 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 -- Adam Lopresto ([EMAIL PROTECTED]) http://cec.wustl.edu/~adam/ Falls don't kill people. It's the deceleration trauma.
RE: perl6 operator precedence table
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
...
$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 .
Literate programming (was Re: perl6 operator precedence table)
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 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
Re: perl6 operator precedence table
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 [EMAIL PROTECTED] 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
Re: perl6 operator precedence table
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 whitespace to be the concatenation operator! my $foo = $bar $bat; ;-) David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: perl6 operator precedence table
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 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 Iconcept 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
Re: perl6 operator precedence table
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 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.
Re: perl6 operator precedence table
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 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
Re: perl6 operator precedence table
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) # $digit is in 0..10 range
array1 like array2 # array intersection
$numlike 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
Re: perl6 operator precedence table
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 Cs 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
RE: perl6 operator precedence table
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 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
Re: perl6 operator precedence table
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 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
Re: perl6 operator precedence table
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
Re: perl6 operator precedence table
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 (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
Re: perl6 operator precedence table
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 : :$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
Re: perl6 operator precedence table
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 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. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: perl6 operator precedence table
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 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 [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED] __ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/
Re: perl6 operator precedence table
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 -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
RE: perl6 operator precedence table
Um, I don't know about your mail program, but mine converts operator:tab to operator:spacespace operator:spacespace Anyone for makefiles? -Original Message- From: David Wheeler [mailto:david;wheeler.net] Sent: Thursday, October 24, 2002 5:59 PM 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+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 -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED] 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.
Re: perl6 operator precedence table
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
:
: $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
Re: perl6 operator precedence table
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
Re: perl6 operator precedence table
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
Re: perl6 operator precedence table
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: 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 Cone/C! as essential as Cany or Call, but:
(a) someone smarter than me will almost certainly
find a killer app for Cone,
(b) the symmetry of:
Logical: || !!
Bitwise: . .| .!
Superpositional: | !
is important...mnemonically, DWIMically, and aesthetically.
Damian
Re: perl6 operator precedence table
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 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
Re: perl6 operator precedence table
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 Cs 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
Re: perl6 operator precedence table
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 Cs 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 Csubst or Csubstitute?
Re: perl6 operator precedence table
Damian wrote: (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 [EMAIL PROTECTED] My parents went to a world without bilateral symmetry and all they brought back was this lousy F-shirt.
Re: perl6 operator precedence table
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 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
Re: perl6 operator precedence table
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 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
Re: perl6 operator precedence table
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 link to be useful: http://www.tobias-jung.de/seekingprofont/ -- ralph
Re: perl6 operator precedence table
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 both MJD and Schwern ...) I investigated and found this link to be useful: http://www.tobias-jung.de/seekingprofont/ Ta. Smylers
Re: perl6 operator precedence table
: 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. 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 ([EMAIL PROTECTED]) http://cec.wustl.edu/~adam/ We've secretly replaced the dilithium with Folgers Crystals.
RE: perl6 operator precedence table
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 )
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Re: perl6 operator precedence table
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 ~? $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
RE: perl6 operator precedence table
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. 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. 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.
RE: perl6 operator precedence table
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 ) : : 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
Re: perl6 operator precedence table
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. 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
Re: perl6 operator precedence table
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 ! $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 [EMAIL PROTECTED]
Re: perl6 operator precedence table
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 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
Re: perl6 operator precedence table
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. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: perl6 operator precedence table
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] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: perl6 operator precedence table
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 terminal font those only differ by a single pixel and it's possible that this could become a source of confusion. Make that a sample size of two. 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. 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 | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: perl6 operator precedence table
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? 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
Re: perl6 operator precedence table
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 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
Re: perl6 operator precedence table
: 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...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
Re: perl6 operator precedence table
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. 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
RE: perl6 operator precedence table
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 ^|= 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
RE: perl6 operator precedence table
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 Cfor 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? The | or doesn't really indicate a superposition in the Cfor. 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 Cfor 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
Re: perl6 operator precedence table
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 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
RE: perl6 operator precedence table
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 Cfor 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.
RE: perl6 operator precedence table
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
Re: perl6 operator precedence table
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.
--
Aaron Crane * GBdirect Ltd.
http://training.gbdirect.co.uk/courses/perl/
Re: perl6 operator precedence table
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 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
Re: perl6 operator precedence table
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 Cfor 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
Re: perl6 operator precedence table
[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 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
Re: perl6 operator precedence table
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 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
Re: perl6 operator precedence table
[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
Re: perl6 operator precedence table
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 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. :-) 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 [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: perl6 operator precedence table
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, 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)
Re: perl6 operator precedence table
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-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. :-)
Re: Fw: perl6 operator precedence table
On Wednesday, October 9, 2002, at 05:03 PM, Trey Harris wrote: In a message dated Wed, 9 Oct 2002, Michael Lazzaro writes: humor Uh-oh: my life is gonna suck. I've spent days hunting obscure bugs that were caused by a single mistyped character. Now I'll be spending days hunting obscure bugs that were caused by a single *pixel*. /humor I've already been there, my friend. :-) MacOS X's pretty anti-aliased fonts make it impossible to tell the difference between colon and semi-colon at small type sizes. It didn't used to matter, but now it really does. I have a hot key to make my terminal's font bigger whenever I'm reading perl6 mail. :-) Andale Mono is all fun and games until someone loses half an hour of their life to: int x, y, z: char ch; :-)
Re: perl6 operator precedence table
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? :-) $x $ybitand($x, $y) $x | $ybitor($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 [EMAIL PROTECTED]
Re: perl6 operator precedence table
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 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 Cfor 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 $ybitand($x, $y)
:$x | $ybitor($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
Re: Fw: perl6 operator precedence table
Larry Wall wrote: [...] Maybe we should ... to mean and so on forever: a[0...; 0...:10; 0...:100] Except then we couldn't use it to mean what Ruby means by it, which might be handier in real life. No more yada-yada-yada? Brad
Re: Fw: perl6 operator precedence table
On Tue, Oct 08, 2002 at 06:07:09PM -0700, Larry Wall wrote:
There's this basic rule that says you can't have an operator for both binary
and postfix, since it's expecting an operator in either case, rather than a
term (which is how we recognize prefix operators). The one exception I can
think of is that we might allow .. as a postfix operator, but only if followed
by a right bracket. That would let us say
a[0..]
rather than
a[0..Inf]
But that's a special case.
Would that mean that three other special cases of postfix .. might exist?
0..; # useful for return 0..;
(0..) # pass infinite lists as parameters with less typing
{0..} # not sure, but it follows on
Nicholas Clark
Re: perl6 operator precedence table
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')
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;
Re: perl6 operator precedence table
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... 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
Re: Fw: perl6 operator precedence table
On Wed, 9 Oct 2002, Nicholas Clark wrote:
: On Tue, Oct 08, 2002 at 06:07:09PM -0700, Larry Wall wrote:
: There's this basic rule that says you can't have an operator for both binary
: and postfix, since it's expecting an operator in either case, rather than a
: term (which is how we recognize prefix operators). The one exception I can
: think of is that we might allow .. as a postfix operator, but only if followed
: by a right bracket. That would let us say
:
: a[0..]
:
: rather than
:
: a[0..Inf]
:
: But that's a special case.
:
: Would that mean that three other special cases of postfix .. might exist?
:
: 0..; # useful for return 0..;
I bet the PDLers want to be able to say: a[0..; 0..:10; 0..:100]
: (0..) # pass infinite lists as parameters with less typing
: {0..} # not sure, but it follows on
I meant those too when I said bracket.
If only we had Unicode editors, we could just force everyone to use
the infinity symbol where they mean it. It seems a shame to make a
special case of the .. operator. Maybe we should ... to mean and so
on forever:
a[0...; 0...:10; 0...:100]
Except then we couldn't use it to mean what Ruby means by it, which
might be handier in real life. (It means to exclude the endpoint,
so 0...4 is the same as 0..3. But then, that's kind of odd too.)
Larry
Re: Fw: perl6 operator precedence table
In a message dated Wed, 9 Oct 2002, Larry Wall writes: If only we had Unicode editors, we could just force everyone to use the infinity symbol where they mean it. It seems a shame to make a special case of the .. operator. Maybe we should ... to mean and so on forever: a[0...; 0...:10; 0...:100] Except then we couldn't use it to mean what Ruby means by it, which might be handier in real life. (It means to exclude the endpoint, so 0...4 is the same as 0..3. But then, that's kind of odd too.) Oh, but then (0...) would mean all numbers from zero to infinity, excluding infinity which would have the same effect in the real world, wouldn't it? :-) Trey
Re: Fw: perl6 operator precedence table
On Wed, Oct 09, 2002 at 10:35:32AM -0700, Larry Wall wrote:
On Wed, 9 Oct 2002, Nicholas Clark wrote:
: On Tue, Oct 08, 2002 at 06:07:09PM -0700, Larry Wall wrote:
: Would that mean that three other special cases of postfix .. might exist?
:
: 0..; # useful for return 0..;
I bet the PDLers want to be able to say: a[0..; 0..:10; 0..:100]
Logically does that mean , also gets in on the special case?
I think it makes sense, as I presume one could pass a couple of infinite lists
to a function that way.
: (0..) # pass infinite lists as parameters with less typing
: {0..} # not sure, but it follows on
I meant those too when I said bracket.
Oops - sorry. I'm so used to American texts that use bracket, brace and
parentheses to mean [] {} () (in that order, IIRC), so I assumed that you
were strictly following that convention.
If only we had Unicode editors, we could just force everyone to use
the infinity symbol where they mean it. It seems a shame to make a
special case of the .. operator. Maybe we should ... to mean and so
on forever:
a[0...; 0...:10; 0...:100]
Except then we couldn't use it to mean what Ruby means by it, which
might be handier in real life. (It means to exclude the endpoint,
so 0...4 is the same as 0..3. But then, that's kind of odd too.)
I think it would be clearer with .. Inf, and however many special cases make
sense. Presumably ] } ) ; : , are all symbols that can't be unary prefix
operators?
And if ... is exclude the endpoint, there's little difference between
0 .. Inf and 0 ... Inf, so the mathematicians can write 0 ... and be happy,
can't they?
Nicholas Clark
--
Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: Fw: perl6 operator precedence table
On Wednesday, October 9, 2002, at 10:35 AM, Larry Wall wrote: Except then we couldn't use it to mean what Ruby means by it, which might be handier in real life. (It means to exclude the endpoint, so 0...4 is the same as 0..3. But then, that's kind of odd too.) humor Uh-oh: my life is gonna suck. I've spent days hunting obscure bugs that were caused by a single mistyped character. Now I'll be spending days hunting obscure bugs that were caused by a single *pixel*. /humor :-) :-) :-) MikeL
Re: Fw: perl6 operator precedence table
On Wed, 9 Oct 2002, Brad Hughes wrote: : Larry Wall wrote: : [...] : Maybe we should ... to mean and so on forever: : : a[0...; 0...:10; 0...:100] : : Except then we couldn't use it to mean what Ruby means by it, which : might be handier in real life. : : No more yada-yada-yada? Still have yada-yada-yada. That's ... when a term is expected, not when an operator is expected. Just don't write 1,2,3... when you mean 1,2,3,... Or vice versa. Larry
Re: Fw: perl6 operator precedence table
On Tue, Oct 08, 2002 at 06:07:09PM -0700, Larry Wall wrote: I've always wondered what the ! postfix operator means. The mathematicians think they know. :-) The Ruby folks think they know. They're method name conventions. From Programming Ruby Methods that act as queries are often named with a trailing '?', such as instance_of?. Methods that are 'dangerous' or modify the receiver, might be named with a trailing '!'. For instance, String provides both a chop and a chop!. The first one returns a modified string; the second modifies the receiver in place. '?' and '!' are the only weird characters allowed as method name suffixes. So... sorted_array = array.sort # return a sorted array array.sort! # sort in place is_sorted = array.sorted? # return true if the array is sorted Interestingly enough, Ruby also supports the ?: operator as Perl does and does not require whitespace between the tokens. $foo=1?42:0; # $foo will have 42 in it. I believe that ? simply binds tighter to method names than the ?: operator. This is fine: print defined? $foo; This is a syntax error: print defined? $foo : 42; /home/schwern/tmp/foo.rb:1: parse error print defined? $foo : 42; ^ -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Cottleston, Cottleston, Cottleston Pie. Why does a chicken, I don't know why. Ask me a riddle and I reply: Cottleston, Cottleston, Cottleston Pie.
Re: perl6 operator precedence table
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 .
: nonassoc++ --
: leftis 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
Re: perl6 operator precedence table
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 : (adverb) or 'is' and 'but' are quite right.
Me either.
: perl6 operator precedence
:
:leftterms and list operators (leftward) [] {} () quotes
:left. and unary .
Unary . can't be left associative. Perhaps unary . is nonassoc like ++.
:nonassoc++ --
:leftis 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.
:nonassoclist operators (rightward)
:right not
I've also considered unifying Cnot 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 Cnot to give its right
side a list context.
:leftand
:leftor xor err
Those are fine. :-)
Larry
Re: Fw: perl6 operator precedence table
On Thu, 26 Sep 2002, Joe Gottman wrote:
: Apocalypse 4 mentions unary '?' . Since this is used to force boolean
: context, I would assume that it has the same precedence as unary '+' and
: '_' which force numeric and string context respectively. By the way, has
: anyone come up with a use for binary '?' yet?
More likely to be a postfix operator. Maybe it even means the same thing:
if ?foo() {...}
if foo()? {...}
I've always wondered what the ! postfix operator means. The mathematicians
think they know. :-)
There's this basic rule that says you can't have an operator for both binary
and postfix, since it's expecting an operator in either case, rather than a
term (which is how we recognize prefix operators). The one exception I can
think of is that we might allow .. as a postfix operator, but only if followed
by a right bracket. That would let us say
a[0..]
rather than
a[0..Inf]
But that's a special case.
Larry
perl6 operator precedence table
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 : (adverb) or 'is' and 'but' are quite right.
perl6 operator precedence
leftterms and list operators (leftward) [] {} () quotes
left. and unary .
nonassoc++ --
leftis 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:
nonassoclist operators (rightward)
right not
leftand
leftor 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
Fw: perl6 operator precedence table
Apocalypse 4 mentions unary '?' . Since this is used to force boolean
context, I would assume that it has the same precedence as unary '+' and
'_' which force numeric and string context respectively. By the way, has
anyone come up with a use for binary '?' yet?
Joe Gottman
- Original Message -
From: John Williams [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, September 26, 2002 8:03 PM
Subject: perl6 operator precedence table
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 : (adverb) or 'is' and 'but' are quite right.
perl6 operator precedence
leftterms and list operators (leftward) [] {} ()
quotes
left. and unary .
nonassoc++ --
leftis 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:
nonassoclist operators (rightward)
right not
leftand
leftor 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
Re: perl6 operator precedence table
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
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
