perl6 regexpisms seen in the wild
Maybe of interest to some, probably of no interest to most, but this is the first time I've noticed the use of a perl6 regexp flag in the wild. Or however wild #london.pm on IRC passes for: richardc Trelane: not really - I think I spent longer debugger +WWW::UsePerl::Journal than I meant to richardc /ger/ging/ richardc :2nd So they are useful :-) (and people will come to use them, and presumably perl6, as they discover that it's more powerful than their current chainsaw. We already assume that, but it's reassuring to find anecdotal evidence that backs it up) Nicholas Clark
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: RFC: [] as the solitary list constructor
On 2002-10-08 at 17:15:06, Larry Wall wrote: Seriously, () is just a special token. We could easily have used a special token like NULLLIST instead. What does INTERCAL use? Well, INTERCAL doesn't have lists per se, but it does have arrays, whose size is set by assignment: the lvalue is the name of the entire array, and the rvalue is the size. So if you wanted an empty array you'd set it up with something like this: PLEASE DO ;1 - #0 (Hey, you asked.) -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754 -- It is not enough to have great qualities, we should also have the management of them. -- La Rochefoucauld
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.
[ANNOUNCE] Perl6 OO Cookbook, v0.1
Yes, you heard right. A cookbook describing stuff that hasn't yet been designed, for a language that doesn't yet exist. Having flashbacks to your college years, anyone? The purpose of the Cookbook is to foster discussion on perl6 OO concepts, and to start documenting the decisions that are made, when they are made: sort of a proto-FAQ. For now, the important part is gathering a comprehensive list of the questions to ask, and some vague stabs at the answers. PLEASE read the About This Document part FIRST for all the appropriate caveats. In particular: - This document has no official status. It's just a first try at something perl6 OO programmers will desperately need. - While the recipes presented represent generally valid questions, the code samples presented are fictional, and will be edited ASAP as the appropriate decisions have been made from the higher-ups. PLEASE contribute to this document! Email me with suggestions, yes or no votes on recipe approaches, info on philosophies or best-guess syntax, etc., or discuss them here on perl6-language. Note that making decisions on any one recipe will naturally allow N other recipes to be decided as well, so this is a great way to break a huge subject into smaller, manageable concepts, and sort through the logical consequences of each. The Perl6 OO Cookbook v0.1 can be accessed at: http://cog.cognitivity.com/perl6/ Ignore the corporate logo, this is my company's site. Have fun, and let me know what you think. MikeL
