y default, the difference between NFC and NFD should be
hidden from users. That implies that, however "Ā" .. "Ē" behaves, the
NFD version should behave identically; and that "B̄" .. F̄ should
behave in the most equivalent way possible.
--
Aaron Crane ** http://aaroncrane.co.uk/
useful.
If the motivation for $*CWD is simply so that it can be temporized,
perhaps it would be better to provide a more direct method of doing
that (preferably using fchdir where available).
--
Aaron Crane ** http://aaroncrane.co.uk/
to suggest that the type names should be C,
C, C.
--
Aaron Crane ** http://aaroncrane.co.uk/
ot; to me. How about
.<*> instead, with its suggestion of "whatever the Match found"?
--
Aaron Crane ** http://aaroncrane.co.uk/
ts own file
offset. Assuming I'm right, that doesn't mean users shouldn't get
access to POSIX dup() for when it *is* what they want.
I agree that also providing a less surprising method would be a good
thing, assuming it can be widely implemented. But it needn't live in
IO::POSIX.
--
Aaron Crane ** http://aaroncrane.co.uk/
Daniel Ruoso writes:
> Em Qua, 2009-02-04 às 16:45 +0000, Aaron Crane escreveu:
> > pugs-comm...@feather.perl6.nl writes:
> > > +=item method Int read($buf is rw, int $length)
> > I'm not sure that using a native int is the right thing here. If
> > whateve
uot; locks, not
"read" and "write" locks
* It seems a little odd to put an flock method in an IO::POSIX role,
given that POSIX specifies fcntl(F_SETLK) in place of traditional
BSD-ish flock(). I'd be in favour of having .fcntl in IO::POSIX, but
with an additional role providing .flock (IO::Flock, presumably).
--
Aaron Crane ** http://aaroncrane.co.uk/
oring a
simple command-line-accessible way of achieving the same thing.
--
Aaron Crane ** http://aaroncrane.co.uk/
quot;iterator".
> +++ doc/trunk/design/syn/S03.pod Mon Mar 17 10:37:26 2008
> +In any case, list assignment is defined to be arbitrarily lazy,
> +insofar is it basically does the obvious copying as long as there
And "insofar as".
--
Aaron Crane ** http://aaroncrane.co.uk/
[EMAIL PROTECTED] writes:
> +defaults to a sequence of 0 values. If any native type is explicitly
> +initialized to C<*> (the C type), it is left unitialized.
s[un <( )> it] = 'in';
(Assuming I've got that syntax correct, anyway.)
--
Aaron Crane
ers" instead? That would still permit things
like $^Item, or caseless letters (Han characters, Japanese kana,
Hangul, Devanagari, Thai, Hebrew, Arabic, etc).
Maybe even "may not consist solely of uppercase Latin-script letters";
that would permit uppercase Greek and Cyrillic and so on.
--
Aaron Crane
Daniel Hulme writes:
> On Fri, Jun 22, 2007 at 03:40:37PM +0100, Aaron Crane wrote:
> > my $b = 1 && 0 || 42;
> > # Now $b is 17
> s/17/42/ or vice-versa, I think.
Uh, yes. Serves me right for trying to change metasyntactic numbers
midstream.
--
Aaron Crane
w $a is 0
my $b = 1 && 0 || 42;
# Now $b is 17
--
Aaron Crane
right argument and
Presumably that should be "number of times".
--
Aaron Crane
ECTED] = @values;
While there's certainly motivation to wrap this up in a function or
operator, it doesn't strike me as something particularly difficult, or
necessarily more worthy of inclusion in Perl 6.0.0 than anything else.
--
Aaron Crane
[EMAIL PROTECTED] writes:
> +The C<:i> (or C<:ignorecase>) modifier causes case distinctions to be
> +ignore in its lexical scope, but not in its dynamic scope. That is,
That should read "ignored", I dare say.
--
Aaron Crane
to the designers of the
language and of its implementation(s). But "I need these operations"
does not imply "Perl 6.0.0 needs these operations".
--
Aaron Crane
[EMAIL PROTECTED] writes:
> +be referred to as C<< COMPILING<$?LINE> >> if the bare C<$?LINE> would
That looks like it's missing a double-colon.
--
Aaron Crane
e value to be
stored (C<++b), and also reads it one further time (to determine the
result of the addition), so it's undefined.
--
Aaron Crane
[EMAIL PROTECTED] writes:
> +the top rule. This may be overridden in either the base grammar or a
> +derived grammer by explicitly naming a rule "top", or defining your
There's a typo there -- "grammer" for "grammar".
--
Aaron Crane
of regexes. Forcing regexes to always use
the C or C prefix sounds inadvisable on Huffman grounds.
--
Aaron Crane
[EMAIL PROTECTED] writes:
> +To pass a regex with leading whitespace you must use the parenthsized form.
...
> +To pass a string with leading whitespace you must use the parenthsized form.
Hi. I think that needs an s:g/parenthsized/parenthesized/
--
Aaron Crane
bitrary Ps/Pe or
bidi-mirroring Unicode pairs), or simply add more brackets:
if 0 { q<<<<
... # >>> with unmatched pointies
>>>> }
--
Aaron Crane
objects
Is that meant to say "value-based"?
--
Aaron Crane
[EMAIL PROTECTED] commits:
> +If the first character is a plus or minus, the initial identifier taken
> +as a character class, so
s/taken/is taken/
--
Aaron Crane
res the same
sense as "environmental". It's also an adjective, which I think reads more
naturally, especially in declarations:
my $foo is context;
say CONTEXT::<$foo>;
versus
my $foo is ambient;
say AMBIENT::<$foo>;
--
Aaron Crane
e to distinguish statement_modifier: from
statement_control:, for both humans and the compiler. One option might
be to require an extra token (a postfix complementizer?) before a statement
modifier. Maybe something like this:
return $foo
--- if $something;
--
Aaron Crane
misunderstanding what you meant). But using "{...}" instead of "@{[...]}"
is definitely a good thing.
--
Aaron Crane
is almost never used. I think the last
time I encountered it was on a dot-matrix printer manufactured in the
1980s.
Hmmm. Encode.pm doesn't seem to have support available for any of the
ISO 646 character sets. I feel a patch coming on.
--
Aaron Crane
Damian Conway writes:
> Just as $42 is a shorthand for $/[42], so too $ is a
> shorthand for $/.
Isn't $42 a shorthand for $/[41] ?
I think that having 1-based digit-variables but 0-based array indexes on
$/ is really confusing; mistakes of this sort seem to confirm my view.
--
Aaron Crane
Luke Palmer wrote:
> Aaron Crane writes:
> > @unsorted
> > ==> sort &infix:<=>, desc => 1, key => { $_.foo('bar').compute }
> > ==> @sorted;
>
> I don't like the C flag. But I can't, at the moment, think of any
er:
@unsorted
==> sort &infix:<=>, desc => 1, key => { $_.foo('bar').compute }
==> @sorted;
What problems can anyone spot with this suggestion?
--
Aaron Crane * GBdirect Ltd.
http://training.gbdirect.co.uk/courses/perl/
o-called-static variables scoped to anything other
than (a group of) subroutines -- they can't be scoped to a loop within a
sub, for example.
--
Aaron Crane * GBdirect Ltd.
http://training.gbdirect.co.uk/courses/perl/
he equivalent
of:
my $stored_identity = $obj.id;
# Time passes...
if ($other_obj.id == $stored_identity) {
# Massive breakage ahoy
}
There just isn't any way you can get .is() to compare identities at different
times.
--
Aaron Crane * GBdirect Ltd.
http://training.gbdirect.co.uk/courses/perl/
ether all of those should have the same .id(). That is, should the
programmer be allowed to determine whether two apparently-identical
numbers have the same representation, or should .id() fudge the issue by
pretending that all representations of a number of a given type are
ident
Sean O'Rourke writes:
> On Thu, 5 Dec 2002, Sean O'Rourke wrote:
> > how 'bout "tang" for "Tog's A Negated Grep"?
>
> Gah. s/Tog/Tang/.
Wouldn't that mean we had to rename grep to 'gnat'? ("Gnat's Not A Tang"
es = @ARGV.cull /^-/;
>
> Array.cull would remove and return a list of every element in @ARGV which
> matched.
I'm not so fond of that -- I don't think it's as obvious that you're doing a
two-way classification.
--
Aaron Crane * GBdirect Ltd.
http://training.gbdirect.co.uk/courses/perl/
out tilde?
@a ~[+] @b
If I'm successfully playing along at home, I think that means the match
operator has to be ~~ or =~, but I can live happily with either of those.
--
Aaron Crane * GBdirect Ltd.
http://training.gbdirect.co.uk/course/perl/
nd I throw in backticks as an extra 'you might also see this'
affair.
Anyway, that was a bit of a rant, but what I mean is: I'd actually be
in favour of avoiding backtick entirely in operators.
--
Aaron Crane * GBdirect Ltd.
http://training.gbdirect.co.uk/courses/perl/
h of these should I type:
@x [+]= @y;
@x [+=] @y;
Of course, the rule ordering didn't matter with the "add a leading ^ to
hype" rule.
I think I prefer the first one, by the way -- it strikes me as more
obviously a vector add.
--
Aaron Crane * GBdirect Ltd.
http://training.gbdirect.co.uk/courses/perl/
ugh (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/
thing else I'd want them for.
* Does this make it harder to write overloaded bitwise ops for your
classes?
--
Aaron Crane * GBdirect Ltd.
http://training.gbdirect.co.uk/courses/perl/
42 matches
Mail list logo
