In order to work with lists of arbitary size, it is often necessary to
split a list into equal sized sub-lists. A Cpart function is proposed
that achieves this:
Are the sublists copies or aliases? I imagine they are aliases,
but this could be specified in the RFC
--
At 01:45 PM 9/4/00 -0600, Tom Christiansen wrote:
package main;
sub fn { return (3, 5, 7) }
tie $x, 'MaiTai';
$x = fn;
$ /tmp/foo
STORE: 7
Why don't I see three STOREs?
Because Perl is too clever to bother. :-)
Hey, waitaminute. That isn't a list in sub fn in the first place; it's
Hey, waitaminute. That isn't a list in sub fn in the first place; it's
three expressions separated by scalar commas. Why is there no complaint
about useless use of a constant in void context?
$ perl -Mstrict -wle 'sub f{return(3,5,7)} my $x = f()'
$ perl -Mstrict -wle 'my $x = (3,5,7)'
Tom Christiansen wrote:
Perl already *has* a print operator: "print". :-)
I think what I really want is a tee operator.
The problem with what you have there is that it hides the act of
output within an arbitrarily long circumfix operator whose terminating
portion is potentially very far
This is what I'd consider good style:
my @output =
map { $_-[0] }
sort { $a-[1] cmp $b-[1] }
map { [$_, expensive_func($_)] } # print original lines
;
(Modified from http://www.perlmonks.org/index.pl?node_id=9108)
The main point of this statement is the Schwartzian
Jon Ericson wrote:
I would want it to return @items:
@sorted = sort print @items;
I'd prefer a different name (tee?) and keep print as it is.
Pretty much all the stuff being discussed right now can be stuck in a
module:
package Print::Variations;
use Exporter;
@EXPORT =
Jon Ericson wrote:
I had considered this, but I don't want Yet Another Quote-like Operator
(YAQO). Perhaps I should just change this RFC to call for a built-in
tee operator:
push @lines, tee($_) for ;
I would vote strongly against a built-in "tee" operator.
You can achieve the same
Michael G Schwern [EMAIL PROTECTED] writes:
On Mon, Sep 04, 2000 at 09:53:39PM -, Perl6 RFC Librarian wrote:
Objects : Core support for method delegation
I like it! One gripe (of course)...
The proposed delegation mechanism would work via a pragma:
use delegation
Damian Conway wrote:
attr3 = [ALL]
It was (and is) a good suggestion. I suspect however that it should be
attr3 = [__ALL__]
Any consideration given to the :all export-like tag?
attr3 = [:all]# could be uppercase too
-Nate
When you want to turn off an inherited delegation in an ISA situation?
Um, I don't think I understand the question.
I'm confused by the question, too.
Delegation is not inherited. Any module you inherit from you won't
use for delegation, AFAIK. They're two different
exists (sometimes causes autovivification, which affects Ckeys)
That's not technically accurate--exists never causes autovivification.
print keys %hash, "\n";
exists $hash{key}{subkey};
print keys %hash, "\n";
Or did that get fixed when I wasn't looking?
Perl6 RFC Librarian [EMAIL PROTECTED] writes:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects : Core support for method delegation
I *want* this. Delegation is cool. Delegation that gets set up at
compile time and is marked as such and can
On Mon, Sep 04, 2000 at 09:53:39PM -, Perl6 RFC Librarian wrote:
The proposed delegation mechanism would work via a pragma:
use delegation
attr1 = [qw( method1 method2 method3 )],
attr2 = [qw( method4 method5 )],
attr3 = [],
I think it's cool too, I don't like the @^g and ^@G either. But I worry
about the double-meaning of the []'s in your solution, and the fact that
these:
/\m[...]...\M/;
/\d[...]...\D/;
Will work so differently. Maybe another character like ()'s that takes a
list:
/\m(,[).*?\M(,])/;
Nathan Wiger wrote:
I think it's cool too, I don't like the @^g and ^@G either. But I worry
about the double-meaning of the []'s in your solution, and the fact that
these:
/\m[...]...\M/;
/\d[...]...\D/;
Well, it's not really a double meaning. It's a set of characters, just
like
Richard Proctor wrote:
No ?] should match the closest ?[ it should nest the ?[s bound by any
brackets in the regex and act accordingly.
Good point.
Also this does not work as a definition of simple bracket matching as you
need ( to match ) not ( to match (. A ?[ list should specify for
David Corbin wrote:
I've got some vague ideas on solving all of these, I'll go into if
people like the basic concept enough.
not just in regexes, but in general, a way to extend the set of bratches
that Perl knows about would be very nice. for instance it is very difficult
for people using
On Tue 05 Sep, David Corbin wrote:
Nathan Wiger wrote:
But, how about a new ?m operator?
/(?m|[).*?(?M|])/;
Let's combine yor operator with my example from above where everything
inside the (?m) or the ?(M)
fits the syntax of a RE.
/(?m()|\[).*?(?M()|(\]))
I think David's on to something good here. A major problem with
holding the bracket-matching possibilities in a special variable
(or a pair of them) is that one can't figure out what the RE is
going to do just by looking at it -- you have to look elsewhere.
Nathan Wiger wrote:
I think it's cool
"Greg Rollins" [EMAIL PROTECTED] writes:
Would the rc support module loading? In other words, a sysadmin might want
to give access to certain Perl modules to his/her users, and not to other
users. That's the only use I can think of for dynamic Perl config. BTW,
it's not something I'm
On Tue, Sep 05, 2000 at 11:16:48AM +1100, Damian Conway wrote:
By RFC 21, it looks like the call would be
if ( want 'LIST' ) {
$num_to_return = want;
# do stuff
}
or, more efficiently:
if ( ($num_to_return) = want 'LIST' ) {
if ( ($num_to_return) = want 'LIST' ) {
# do stuff
}
And more correct as I would assume that
() = some_func();
$num_to_return would be zero, but the assignment would cause the
if() to be true.
A scalar context Cwant would
Damian Conway wrote:
if ( ($num_to_return) = want 'LIST' ) {
# do stuff
}
$num_to_return would be zero, but the assignment would cause the
if() to be true.
A scalar context Cwant would also need to DWIM, presumably by returning
"0,
On Wed, 6 Sep 2000 05:33:27 +1100 (EST), Damian Conway wrote:
A scalar context Cwant would also need to DWIM, presumably by returning
"0, but true" in that (unusual) situation.
I don't understand the existence of that phrase, and the fact that it
doesn't give a warning when used in numerical
A scalar context Cwant would also need to DWIM, presumably by returning
"0, but true" in that (unusual) situation.
Actually, given Damian's and my conversations last night, it looks like
the first return arg from want() is going to be the context after all
(since then
=head1 ABSTRACT
When programming in perl we need really often to calculate
union, intersection, difference between arrays. It will be
cool if such functions could be part of the perl6 language.
Arrays/Lists are ordered, sets are not.
For sets, hashes are a better perl representation.
David L. Nicol wrote:
For sets, hashes are a better perl representation.
I think you must have missed some of this discussion.
Rather than reiterate my contributions, I'll point you into the archive:
http://www.mail-archive.com/perl6-language%40perl.org/msg03425.html
On Tue, 5 Sep 2000 10:48:45 +0200, dLux wrote:
/--- On Mon, Sep 04, 2000 at 07:18:56PM -0500, Greg Rollins wrote:
| Will perl monitor the commit and rollback actions of transactions?
\---
What exactly you mean?
And did you have to quote 500+ lines of the RFC just to add this one
sentence?
--
/--- On Mon, Sep 04, 2000 at 07:18:56PM -0500, Greg Rollins wrote:
| Will perl monitor the commit and rollback actions of transactions?
\---
What exactly you mean?
dLux
--
This message is READ-ONLY
29 matches
Mail list logo
