John Williams wrote:
Good point. Another one is: how does the meta_operator determine the
identity value for user-defined operators?
Does it have to? The definition of the identity value---BTW, I like
the term neutral value better because identity also is a relation
between two values---is that
I was doing some work on Parrot::Test today and was replacing this code
with something more cross platform.
# Run the command in a different directory
my $command = 'some command';
$command= cd $dir $command if $dir;
system($command);
I replaced it with this.
David Wheeler skribis 2005-04-14 21:32 (-0700):
I was going to say that that was inconsistent, but since you never need
to repeat a letter in a character class, well, I guess it isn't. But
the first person to write [a...] gets what's comin' to 'em.
Given ASCII, [\x20...] would then be
- Original Message -
From: Aaron Sherman [EMAIL PROTECTED]
To: David Wheeler [EMAIL PROTECTED]
Cc: Perl6 Language List perl6-language@perl.org
Sent: Friday, April 15, 2005 2:00 PM
Subject: Re: should we change [^a-z] to -[a..z] instead of -[a-z]?
On Thu, 2005-04-14 at 21:32 -0700,
Am I the only one who thinks [a-z] is ugly and hard to type because of
the nested brackets? The same goes for {...}. The latter can't easily
be fixed, I think, but the former perhaps can. If there are more who
think it needs to, that is. And {} is a bit easier to type because all
four are shifted
On Fri, Apr 15, 2005 at 02:58:44PM +0200, Juerd wrote:
Am I the only one who thinks [a-z] is ugly and hard to type because of
the nested brackets? The same goes for {...}. The latter can't easily
be fixed, I think, but the former perhaps can.
Part of the thinking behind this is that the [...]
delurk
even sillier question:
if [a.z] matches a, . and z
and [a...] matches all characters from a including (for some
definition of 'all')
how will be range \x21 .. \x2e written?
[!..\.]? (i.e. . escaped?)
/delurk
I was assuming from Larry's mail that [a...] would parse as either:
On 14 Apr, Larry Wall wrote:
: In writing some character class translation, I realized that
:
: -[a-z]
:
: and its ilk are rather hard to read because of the two hyphens
: that mean different things. We can't use ![a-z] because that's a
: 0-width lookahead. Given that we're trying to get
Aaron Sherman wrote in perl.perl6.language :
A silly question: is there a canonical character set from which we
extract these ranges? Are we hard-coding Unicode here, or is there some
way for the user to specify the character set for ranges?
Perl 5 forces [a-z] (or [i-j] for that matter) to
On Fri, Apr 15, 2005 at 01:01:58PM -, Rafael Garcia-Suarez wrote:
Aaron Sherman wrote in perl.perl6.language :
A silly question: is there a canonical character set from which we
extract these ranges? Are we hard-coding Unicode here, or is there some
way for the user to specify the
On Fri, Apr 15, 2005 at 03:11:59AM -0700, Michael G Schwern wrote:
: Error handling is simple, a failed chdir returns undef and sets errno.
:
: $CWD = $dir err die Can't chdir to $dir: $!;
Offhand, I guess my main semantic problem with it is that if a chdir
fails, you aren't in an
Among the various ways of declaring variables, will Perl 6 have a way to
say, this variable is highly temporary, and may be re-declared within
the same scope, or in a nested scope without concern? I often find
myself doing:
my $sql = q{...};
...do some DB stuff...
my $sql
On Fri, Apr 15, 2005 at 12:45:14PM +1200, Sam Vilain wrote:
: Larry Wall wrote:
: Well, only if you stick to a standard dialect. As soon as you start
: defining your own macros, it gets a little trickier.
:
: Interesting, I hadn't considered that.
:
: Having a quick browse through some of the
Aaron Sherman skribis 2005-04-15 11:45 (-0400):
What I'd really like to say is:
throwawaytmpvar $sql = q{...};
throwawaytmpvar $sql = q{...};
I like the idea and propose a, aliased an for this.
It should probably be illegal to:
throwawaytmpvar $sql = q{...};
my $sql
On Fri, Apr 15, 2005 at 11:45:16AM -0400, Aaron Sherman wrote:
: Among the various ways of declaring variables, will Perl 6 have a way to
: say, this variable is highly temporary, and may be re-declared within
: the same scope, or in a nested scope without concern? I often find
: myself doing:
:
On Fri, Apr 15, 2005 at 06:04:32PM +0200, Juerd wrote:
: No, Ucfirst it can't be, I think. And ALLCAPS is ugly. @ is taken (and
: ugly). Suggestions?
Maybe we could define an ok operator that suppresses only the
*first* warning produced by its argument(s). Then if you get multiple
warnings, you
On Fri, Apr 15, 2005 at 09:17:13AM -0700, Larry Wall wrote:
On Fri, Apr 15, 2005 at 06:04:32PM +0200, Juerd wrote:
: No, Ucfirst it can't be, I think. And ALLCAPS is ugly. @ is taken (and
: ugly). Suggestions?
Maybe we could define an ok operator that suppresses only the
*first* warning
David Wheeler wrote:
But the first person to write [a...] gets what's comin' to 'em.
Is that nothing (since '.' lt 'a'), or everything after 'a'?
-- Rod Adams
Larry Wall wrote:
On Fri, Apr 15, 2005 at 06:04:32PM +0200, Juerd wrote:
: No, Ucfirst it can't be, I think. And ALLCAPS is ugly. @ is taken (and
: ugly). Suggestions?
Maybe we could define an ok operator that suppresses only the
*first* warning produced by its argument(s). Then if you get
Rod Adams skribis 2005-04-15 11:53 (-0500):
Wouldn't some form of trait make more sense:
my $sql = '...' is ok;
Depends. A unary ok operator would let you pinpoint very easily,
*without* using parens:
ok $fh.print($foo); # no warnings about print (closed fh?)
#
Aaron Sherman writes:
Among the various ways of declaring variables, will Perl 6 have a way to
say, this variable is highly temporary, and may be re-declared within
the same scope, or in a nested scope without concern? I often find
myself doing:
my $sql = q{...};
...do some DB
The following chunks behave the same in Perl 5.6 as in Perl 5.8. Notice the
output of branching statement modifiers vs. looping statement modifiers.
perl -e '$f=1; {local $f=2; print $f} print - $f\n'
# prints 2 - 1
perl -e '$f=1; {local $f=2 if 1; print $f} print - $f\n
# prints 2 - 1
Paul Seamons skribis 2005-04-15 11:50 (-0600):
my %h = a 1 b 2 c 3;
{
temp %h{$_} ++ for %h.keys;
Just make that two lines. Is that so bad?
temp %h;
%h.values »++;
%h.say; # values are incremented still
}
%h.say; # values are back to original values
Juerd
--
Aaron Sherman [EMAIL PROTECTED] wrote:
What I'd really like to say is:
throwawaytmpvar $sql = q{...};
throwawaytmpvar $sql = q{...};
Anything wrong with:
my $sql = q{...};
temp $sql = q{...};
temp $sql = q{...};
(Assuming Ctemp is made to work on lexicals, of
On Friday 15 April 2005 11:57 am, Juerd wrote:
Paul Seamons skribis 2005-04-15 11:50 (-0600):
my %h = a 1 b 2 c 3;
{
temp %h{$_} ++ for %h.keys;
Just make that two lines. Is that so bad?
temp %h;
%h.values »++;
For the given example, your code fits perfectly. A more common
Brent 'Dax' Royal-Gordon skribis 2005-04-15 11:15 (-0700):
Anything wrong with:
Yes, moving things around breaks it, as does removing the first. There
is no real dependency on the first $sql and it'd be great if declaration
wouldn't add one.
temp $sql = q{...};
my $sql = q{...};
temp
On Fri, 2005-04-15 at 11:21 -0500, Patrick R. Michaud wrote:
On Fri, Apr 15, 2005 at 09:17:13AM -0700, Larry Wall wrote:
Maybe we could define an ok operator that suppresses only the
*first* warning produced by its argument(s). Then if you get multiple
warnings, you at least get some
Paul Seamons skribis 2005-04-15 12:16 (-0600):
For the given example, your code fits perfectly. A more common case I have
had to deal with is more like this:
my %h = a 1 b 2 c 3
my %other = a one b two;
{
temp %h{$_} = %other{$_} for %other.keys;
Either
temp %h;
%h{$_} =
temp %h;
%h{ %other.keys } = %other.values;
or even
temp %h{ %other.keys } = %other.values;
should work well already?
Almost - but not quite.
In Perl5
perl -MData::Dumper -e '%h=qw(a 1 b 2); {local %h; $h{a}=one; print Dumper
\%h} print Dumper \%h;
$VAR1 = {
'a' =
On Fri, 2005-04-15 at 13:10, Luke Palmer wrote:
Aaron Sherman writes:
Among the various ways of declaring variables, will Perl 6 have a way to
say, this variable is highly temporary, and may be re-declared within
the same scope, or in a nested scope without concern? I often find
myself
On Friday 15 April 2005 12:28 pm, Juerd wrote:
temp %h{ %other.keys } = %other.values;
Oops missed that - I like that for solving this particular problem. It does
even work in Perl5:
perl -MData::Dumper -e '%h=qw(a 1 b 2); {local @h{qw(a b)}=(one,two);
print Dumper \%h} print Dumper \%h'
On Fri, Apr 15, 2005 at 11:28:31AM -0500, Rod Adams wrote:
: David Wheeler wrote:
:
: But the first person to write [a...] gets what's comin' to 'em.
:
: Is that nothing (since '.' lt 'a'), or everything after 'a'?
Might as well make it everything after 'a' for consistency. One could
also view
Paul Seamons skribis 2005-04-15 12:41 (-0600):
In Perl5
perl -MData::Dumper -e '%h=qw(a 1 b 2); {local %h; $h{a}=one; print Dumper
\%h} print Dumper \%h;
$VAR1 = {
'a' = 'one'
};
$VAR1 = {
'a' = '1',
'b' = '2'
};
I'm imaging the behavior
I would like to get rid of all those implicit scopes. The only
exception would be that any topicalizing modifier allocates a private
lexical $_ scoped to just that statement. But dynamic scoping may
happen only at explicit block boundaries.
I can see the argument for the other side, where any
I'm imagining it will be different, as I expect temp to not hide the old
thing. I'm not sure it will.
That is another good question. I just searched through the S and A's and
couldn't find if temp will blank it out. I am thinking it will act like
local. Each of the declarations my, our and
Thus spake Larry Wall:
Offhand, I guess my main semantic problem with it is that if a chdir
fails, you aren't in an undefined location, which the new value of $CWD
would seem to indicate. You're just where you were. Then the user
either has to remember that, or there still has to be some
Paul Seamons skribis 2005-04-15 13:42 (-0600):
Each of the declarations my, our and local currently set the value to
undefined (unless set = to something).
That's not true.
use strict;
$::foo = 5;
our $foo;
print $foo; # 5
Juerd
--
Michael G Schwern skribis 2005-04-15 13:12 (-0700):
To be clear: Only the store operation will return undef on failure.
Additional fetches on $CWD will continue to return the cwd.
Still breaks
$ref = \($CWD = $foo);
I'm not sure this breakage matters, but if it breaks one thing, it's
On Fri, Apr 15, 2005 at 01:12:46PM -0700, Michael G Schwern wrote:
: Thus spake Larry Wall:
: Offhand, I guess my main semantic problem with it is that if a chdir
: fails, you aren't in an undefined location, which the new value of $CWD
: would seem to indicate. You're just where you were.
Pasted from pugs/examples/cookbook/01-00introduction.p6:
# XXX - question: How equal are bunches of spaces to tabs?
# -- I'd say that's a question for perl6lang
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
On Fri, 2005-04-15 at 23:52 +0200, Juerd wrote:
Well, after failure it can be cwd() but false without breaking any real
code, because normally, you'd never if (cwd) { ... }, simply because
there's ALWAYS a cwd.
Not always -- try removing a directory that's the pwd of another
process.
-- c
On Fri, 2005-04-15 at 17:44, Juerd wrote:
Is there a ?ws-like thingy that is always \s+?
Not sure what that means exactly.
Do \s and ?ws match non-breaking whitespace, U+00A0?
As I understood, Perl 6 was going to use the Unicode standard(s) to
determine the whitespacishness of each codepoint.
Aaron Sherman skribis 2005-04-15 18:20 (-0400):
Is there a ?ws-like thingy that is always \s+?
Not sure what that means exactly.
?ws is \s* or \s+, depending on its surroundings.
Thankfully, NBSP (U+00A0) is not Unicode whitespace.
Thanks for sharing this information!
Juerd
--
On Fri, Apr 15, 2005 at 11:44:03PM +0200, Juerd wrote:
: Is there a ?ws-like thingy that is always \s+?
Not currently, since \s+ is there. ?ws used to be that, but
currently is defined as the magical whitespace matcher used by :words.
: Do \s and ?ws match non-breaking whitespace, U+00A0?
Yes.
Larry Wall skribis 2005-04-15 15:38 (-0700):
: Do \s and ?ws match non-breaking whitespace, U+00A0?
Yes.
That makes \s+ and \s*, and thus ?ws very useless for anything but
trimming whitespace. For splitting (including word wrapping), it'd do
exactly the wrong thing.
: \s is said (in S05) to
On Sat, Apr 16, 2005 at 12:11:24AM +0200, Juerd wrote:
: Pasted from pugs/examples/cookbook/01-00introduction.p6:
:
: # XXX - question: How equal are bunches of spaces to tabs?
: # -- I'd say that's a question for perl6lang
This seems to be singularly short on context, but if it has to do
On Sat, Apr 16, 2005 at 12:46:47AM +0200, Juerd wrote:
: Larry Wall skribis 2005-04-15 15:38 (-0700):
: : Do \s and ?ws match non-breaking whitespace, U+00A0?
: Yes.
:
: That makes \s+ and \s*, and thus ?ws very useless for anything but
: trimming whitespace. For splitting (including word
I thought we had just established that nbsp is not in Unicode¹s definition
of whitespace. So why should \s match it?
On 2005-04-15 18:56, Larry Wall [EMAIL PROTECTED] wrote:
On Sat, Apr 16, 2005 at 12:46:47AM +0200, Juerd wrote:
: Larry Wall skribis 2005-04-15 15:38 (-0700):
: : Do \s and
More questions stemming from cookbook work... Decimal Comparisons:
The most common recipe around for comparisons is to use sprintf to cut
the decimals to size and then compare strings. Seems ugly.
The non-stringification way to do it is usually along the lines of:
if (abs($value1 - $value2)
At 16:18 -0700 4/15/05, gcomnz wrote:
More questions stemming from cookbook work... Decimal Comparisons:
The most common recipe around for comparisons is to use sprintf to cut
the decimals to size and then compare strings. Seems ugly.
The non-stringification way to do it is usually along the
On Fri, Apr 15, 2005 at 11:52:38PM +0200, Juerd wrote:
becomes an unverifiable operation. You have to use chdir() if you want to
error check and $CWD is reduced to a scripting feature.
Well, after failure it can be cwd() but false without breaking any real
code, because normally, you'd
On Fri, Apr 15, 2005 at 03:22:48PM -0700, Michael G Schwern wrote:
: On Fri, Apr 15, 2005 at 11:52:38PM +0200, Juerd wrote:
: becomes an unverifiable operation. You have to use chdir() if you want to
: error check and $CWD is reduced to a scripting feature.
:
: Well, after failure it can
According to Michael G Schwern:
And this is exactly what File::chdir does. $CWD is a tied scalar.
I don't think current directory maps well on a variable. That won't
stop people from using it, of course. :-(
There are several methods to determine the current directory. Each
one has its
According to chromatic:
On Fri, 2005-04-15 at 23:52 +0200, Juerd wrote:
Well, after failure it can be cwd() but false without breaking any real
code, because normally, you'd never if (cwd) { ... }, simply because
there's ALWAYS a cwd.
Not always -- try removing a directory that's the pwd
On Fri, Apr 15, 2005 at 08:31:57PM -0400, Chip Salzenberg wrote:
According to Michael G Schwern:
And this is exactly what File::chdir does. $CWD is a tied scalar.
I don't think current directory maps well on a variable. That won't
stop people from using it, of course. :-(
There are
55 matches
Mail list logo
