Re: Renaming grep
On Nov 19, 2005, at 13:08 , Chip Salzenberg wrote: On Sat, Nov 19, 2005 at 05:46:51AM +0200, Ilmari Vacklin wrote: I don't much like it - it looks like a mistyped 'shift'. Is 'filter' too long? I usually avoid P6L discussions, but: GNU Make has filter and filter-out, and I've always found the polarity hard to remember. I like grep. I like grep, too. FYI google gave me 6,650,000 greps and 4,390,000 sifts. IMHO grep is popular enough. Well, google gave me some 158,000,000 filters but that's rather too common and ambiguous. Note filter does not always sift (i.e. perl - ple '$_=$.:$_'). Dan the (grepp|sift|filter)ed Man
Re: Private behavior in roles
On Thu, Nov 17, 2005 at 01:55:31PM -0800, Ovid wrote:
: In http://perlmonks.org/?node_id=509413 (in response to
: http://perlmonks.org/?node_id=509256), Rob Kinyon wrote that in his
: understanding of Perl 6 Roles, anything a role can do the class doing
: the role should also be able to do.
:
: Is this correct?
Only sorta. A role has its own lexical scope that the class is not
privy to, and lately we're trying to manage privacy via lexical scoping
as much as possible.
: I'm getting bitten with Class::Trait because some of
: my traits import helper functions and constants from other packages.
: The classes implementing the traits should *not* care about how the
: trait does something, but those functions and constants are getting
: flattened into my classes and this has been causing all sorts of
: problems.
In Perl 6 imports are lexical by default, so that shouldn't be a problem.
: For the time being, I have rewritten all of my traits to not import
: anything in the trait namespace, but I intend to modify Class trait so
: each method can be defined thusly:
:
: sub some_method : Public { ... }
:
: In the original traits definition, as I understood them, a trait should
: specify what it requires *and* what it provides. Are Perl 6 roles
: really going to blindly export everything they contain? This seems a
: serious mistake. I didn't see anything addressing this issue in
: http://www.perl.com/pub/a/2004/04/16/a12.html?page=12
Please don't rely on perl.com for the latest design docs. I just
checked in a new S12 to svn.perl.org a few minutes ago that hopefully
covers most of the questions raised here and on perlmonks. Doubtless
there will be more issues, but that's the nature of the beast.
I'll need to go and install some Update sections in A12, but bein's as
it's 2:00 in the morning I'm going to bed...
Larry
Re: Classification syntax [Was: Renaming grep]
On Fri, Nov 18, 2005 at 11:36:33 -0800, Larry Wall wrote:
If we had some kind of partitioning operator, it'd probably be generalized
to sorting into bins by number, where 0 and 1 are degenerate cases for
booleans. But since we'd almost certainly make the general form
(@bin0, @bin1, @bin2...) := classify { calc_int($_ } LIST;
For me it seems to make more sense that in the higher-order scheme
of things classify presents functions to it's body. Instead of
relying on the return value from the body, it gets a number of
functions that it can invoke to append a function.
This is more general since it allows classification to include
duplicates.
Grep is simply:
sub grep (filter, [EMAIL PROTECTED]) {
classify - $x, f {
f($x) if filter($x);
} [EMAIL PROTECTED];
}
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me does not drink tibetian laxative tea: neeyah!
pgp0EJd1MZfCg.pgp
Description: PGP signature
lvalue reverse and array views
In Perl 5,
for (reverse @foo) { $_ = $_ + 1 }
actually works. But reverse does not return lvalues, which means that:
(reverse @foo) = map $_ + 1, @foo;
does not do the same thing, but actually throws an exception.
I think, but haven't confirmed, that the for-reverse is an
optimization resulting in an undocumented feature. This is something I
hope Perl 6 will avoid, but that raises the following question:
Will Perl 6 support mutable for-reverse?
Some possible answers that I could think of:
(a) Yes, but as a special case
(b) Yes, because reverse returns lvalue aliases
(c) No
But there's another one, that I didn't immediately think of:
(d) Yes, because reverse @foo always behaves like an array (rather than
a function that *returns* a list), just with a different view: the
elements are in the wrong order.
This option d is interesting, and would probably be nice to have,
because it would also allow this (contrived and useless) kind of thing:
push reverse(@foo), $bar;
And while that isn't very interesting, I think something like
my @bar := reverse @foo;
would be very useful. Insert an element between positions 1 and 2, and
the original @foo array gets them between positions -3 and -2.
The same thing would be interesting for zip:
my @xyzzy := @foo Y @bar;
Assuming this results in an even number of elements in @xyzzy, pushing a
single element onto @xyzzy could result in an element added to @foo
every odd, and to @bar every even time.
Would something like that be possible? Wanted? Not too costly?
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
\x{123a 123b 123c}
Maybe
\x{123a 123b 123c}
is a nice alternative of
\x{123a} \x{123b} \x{123c}.
--
Grtz, Ruud
Re: \x{123a 123b 123c}
Ruud H.G. van Tol skribis 2005-11-20 1:19 (+0100):
Maybe
\x{123a 123b 123c}
is a nice alternative of
\x{123a} \x{123b} \x{123c}.
Hmm, very cute and friendly! Can we keep it, please? Please?
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: \x{123a 123b 123c}
On Sun, Nov 20, 2005 at 01:26:21AM +0100, Juerd wrote:
: Ruud H.G. van Tol skribis 2005-11-20 1:19 (+0100):
: Maybe
: \x{123a 123b 123c}
: is a nice alternative of
: \x{123a} \x{123b} \x{123c}.
:
: Hmm, very cute and friendly! Can we keep it, please? Please?
We already have, from A5, \x[0a;0d], so you can supposedly say
\x[123a;123b;123c]
Note that square brackets are now the normative style though, since we're
trying to reserve curlies psychologically for closures.
But I see that the semicolon is rather cluttery, mainly because it's
too tall. I'm not sure going all the way to space is good, but we
might have
\x[123a,123b,123c]
just to get a little visual space along with the separator. My problem
with space is that it has potential visual confusion with character
classes (especially with the square brackets), and it also will make
people wonder whether :w should match optional whitespace between
the characters. The commas seems to imply sequence to me, and they
occur often enough that you can see it's not a well-formed character
class, insofar as it has repeated characters.
It occurs to me that we didn't spec whether character classes ignore
whitespace. They probably should, just so you can chunk things:
/ [ a..z A..Z 0..9 _ ] /
Then the question arises about whether [ \ ] is an escaped space
or a backslash, or illegal But if we make it match a backslash
or illegal, then the minimal space matcher becomes \x20, I think,
unless you graduate to \s. On the other hand, if we make it match
a space, people aren't going to read that way unless they're pretty
sophisticated...
Larry
Re: lvalue reverse and array views
Juerd [EMAIL PROTECTED] writes: I think something like my @bar := reverse @foo; would be very useful. Insert an element between positions 1 and 2, and the original @foo array gets them between positions -3 and -2. That would be cool. The concept is reminiscent of using a change of basis to make your coordinates look nicer in a vector space or something. Reversing an array, changing it, and then rereversing it --- I think that kind of pattern is common. The same thing would be interesting for zip: my @xyzzy := @foo Y @bar; Assuming this results in an even number of elements in @xyzzy, pushing a single element onto @xyzzy could result in an element added to @foo every odd, and to @bar every even time. Well, wouldn't pushing an element onto @xyzzy be more like pushing the car to @foo and the cdr to @bar, or throwing an exception if the new element is not a Pair? (What is Perl's pair terminology, by the way?) -- Daniel Brockman [EMAIL PROTECTED]
