Re: Proposed RFC for matrix indexing and slicing
Buddha Buck wrote: Boy, there are a lot of people on that CC: list... Anyone want off this ride? How would you recommend the RFC breakdown? Use ";" for matrix index separator Use named iterators for matrix indices anything else? Everyone else is way past brainstorming but here is two anything elses use $" for matrix index separator. use $; for matrix index separator. use /\D+/ for matrix index seperator
RFC 191 (v1) smart container slicing
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
smart container slicing
=head1 VERSION
Maintainer: David Nicol [EMAIL PROTECTED]
Date: 1 September 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 191
Status: Developing
=head1 ABSTRACT
a more concise syntax for matching all the elements in a container that
are stored under keys that meet a condition
=head1 DESCRIPTION
What if, instead of requiring
@onesIwant = @hash{grep /restriction on keys/ keys %hash};
one could simply write
@onesIwant = @hash{/restriction on keys/};
to obtain a list of all items stored in Chash under keys containing
the string C'restriction on keys'
=head1 IMPLEMENTATION
When interpreting the appearance of a single regex (including an object
resulting from a Cqr//) inside braces indicating container lookup,
in a "slicing" context, the regex is applied to the keys of the container
and the matching elements are returned, as per the longer syntax involving
an intermediate anonymous array.
=head1 CONFLICTS
In situations where one wants to pull a list of one item
out of a hash in which that item is keyed with a regex, assuming such
is possible, one will need to use
@listofoneitem = ( $hash{$regex} );
instead of the syntax appropriated by this suggestion.
=head1 BUT WAIT THERE'S MORE
With the addition to the language of regular expression syntax to
deal numbers by value rather than is done now, the syntax described
in this document may provide a concise way to slice multidimensional
containers.
=head1 REFERENCES
Re: The distinction between do BLOCK while COND and EXPR while COND should go
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
TC Well, that depends. Often you must delay till run-time. When Perl
TC simply sees something like:
TC sub fn { return @blah }
TC it can't know whether you'll use that as:
TC $x = fn();
TC or
TC @x = fn();
TC or
TC fn();
I think with the -internals idea of pushing a thingee on the stack
rather than flattening the list, the actual effect of the assingment
can easily be delayed with little cost to runtime.
Though Randal will jump all over me. It might be worthwhile enough
to kill
sub fn { return (7,8,9,10) }
$x = fn(); # $x == 10
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 181 (v1) Formats out of core / New format syntax
Have you also looked at Damian's Text::Autoformat, which has a renewed format implementation that looks *very* good a candidate for replacing perl 4/5's format. Yes, I have. It's actually very powerful. I've actually been meaning to talk to Damian about this, because at one time he had mentioned proposing a modification of it to replace Perl's formats. In which case, this would obviously be integrated here. write [format_name] [filehandle]; I don't know if I want a comma there, I think yes, but ... Well, if we did it this way, what we'd actually want is: write $FILEHANDLE $FORMAT; The reason is this could use Perl's indirect object notation: $FILEHANDLE-write($FORMAT); Automatically. Plus, it preserves the current write() syntax intact. This is what I was going to put in v2. If there is a need for migration anyway, look at Damian's implementation again and add new functionality at the same time, like footers. Agreed. I wanted to get the basic idea out there so people could start thinking about it. my format $FILE_FORMAT = @: @ $name, $ssn . And get rid of the '$' too. If it's feasable in your mind to do it in the perl6 parser, it would also be possible to move that to the perl5-perl6 converter. Can't do that. This syntax simply declares a lexical variable $FILE_FORMAT of type format, which is a special variable class that could compile formats for use by write. Removing the $ would be a bad idea; it would special-case one variable name in one specific instance. Both filehandles and file formats should be $scalars in Perl 6. -Nate
Re: RFC 171 (v2) my Dog $spot should call a constructor implicitly
On Fri, Sep 01, 2000 at 10:58:36AM -0800, Michael Fowler wrote: my $spot isa(Dog); This should be my $spot : isa(Dog); Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: RFC 171 (v2) my Dog $spot should call a constructor implicitly
Michael Fowler wrote:
On Fri, Sep 01, 2000 at 11:41:47AM -0700, David E. Wheeler wrote:
Michael Fowler wrote:
my Dog $spot; # $spot is now a blessed Dog object
$spot-name("Fido");# $spot-{'name'} eq "Fido"
print ref $spot;# yes, "Dog"
$spot = new Dalmation; # now $spot is a Dalmation object
Yes, but the Dalmation $spot will *not* have the name "Fido," will it?
Nope, $spot is now an entirely new object.
Well then, that makes this example rather wasteful, doesn't it?
my Dog $spot;
if ($input eq 'Collie') {
$spot = Collie-new;
} elsif ($input eq 'Dalmation') {
$spot = Dalmation-new;
}
Becuase we're creating two objects when we really only want one.
David
Re: RFC 171 (v2) my Dog $spot should call a constructor implicitly
On Fri, Sep 01, 2000 at 12:35:24PM -0700, David E. Wheeler wrote:
Well then, that makes this example rather wasteful, doesn't it?
It wasn't an example of how my Dog $spot should be used. I was explaining
to Nate what his code was doing.
my Dog $spot;
if ($input eq 'Collie') {
$spot = Collie-new;
} elsif ($input eq 'Dalmation') {
$spot = Dalmation-new;
}
Becuase we're creating two objects when we really only want one.
Yes. That my Dog $spot should be either my $spot or my $spot : isa(Foo)
(which I just recently made up) in this case.
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: RFC 190 (v1) Objects : NEXT pseudoclass for method redispatch
On Fri, Sep 01, 2000 at 08:59:10PM -, Perl6 RFC Librarian wrote: This RFC proposes a new pseudoclass named CNEXT. This pseudoclass would provide a way of correctly redispatching a method or an autoloaded method. Yay! I have nothing constructive to say. (Yay!) -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse But why? It's such a well designed cesspool of C++ code. Why wouldn't you want to hack mozilla? -- Ziggy
Re: RFC 189 (v1) Objects : Hierarchical calls to initializers and destructors
On 9/1/00 5:44 PM, Nathan Wiger wrote:
sub SETUP {
my ($self, @ctor_data) = @_;
# initialization of object referred to by $self occurs here
}
Hmmm. I'm not sure if I like this. I like the *idea* a lot, but I must
say that I think I quite like RFC 171's approach better.
I haven't commented on RFC 171 because I assumed it would be shot down
quickly by the Major Contibutors(tm), but let me just say now that I'm
firmly in this camp:
On 9/1/00 5:58 AM, Bart Lateur wrote:
If you want a constructor called, than FGS *call* a constructor. Maybe you can
reduce the syntax necessary to do that, but please don't do it behind our
backs.
And I'll further add that I like Damian's RFCs on the topic, having
essentially duplicated that functionality "by hand" myself at various
times, and found it to be very useful and friendly. (Although I
used "init" instead of "SETUP" but I guess there already is an "INIT")
-John
Re: RFC 189 (v1) Objects : Hierarchical calls to initializers anddestructors
I haven't commented on RFC 171 because I assumed it would be shot down
quickly by the Major Contibutors(tm), but let me just say now that I'm
firmly in this camp:
Funny, I don't see much difference between RFC 171 and this RFC:
171: constructor called on object creation
189: constructor called on object blessing
Both of them suffer from involuntary method calls and no way to prevent
them.
And I'll further add that I like Damian's RFCs on the topic, having
essentially duplicated that functionality "by hand" myself at various
times, and found it to be very useful and friendly. (Although I
used "init" instead of "SETUP" but I guess there already is an "INIT")
I like the *idea* to a lot. But I don't like the hooks being in bless.
What if you want to bless something but not call all its cascading
SETUPs? I'd much rather the hooks be somewhere else, like new builtin.
Maybe 'setup'?
sub new { setup {}, @_ }
sub SETUP {
my ($self, @ctor_data) = @_;
# initialization of object referred to by $self occurs here
}
setup() could do the blessing + call recursive SETUPs. Just calling
bless() would retain the Perl 5 behavior.
-Nate
Re: RFC 189 (v1) Objects : Hierarchical calls to initializers anddestructors
What happens on reblessing? An excellent question, and one that has been exercising my mind for some time now. I have come to the conclusion that a reblessing must either: * invoke the old class's DESTROY(s) and then invoke the new class's SETUP(s), or * invoke some other hierarchy of automagic methods (REFIT? RESHAPE? MORPH? TRANSMOGRIFY?), or * do nothing. The first behaviour is by far the safest, but would seem to defeat the entire purpose of reblessing. The last behaviour is the most flexible but forfeits guaranteed clean-up. The middle option is annoying because it adds yet another magic method. But suspect it is the correct response. Damian
Re: RFC 189 (v1) Objects : Hierarchical calls to initializers and destructors
On Fri, Sep 01, 2000 at 08:59:10PM -, Perl6 RFC Librarian wrote:
=head1 ABSTRACT
This RFC proposes a new special method called CSETUP that is
invoked automagically whenever an object is created. Furthermore,
it proposes that both CSETUP and CDESTROY methods should
be invoked hierarchically in all base classes.
I agree with Michael that SETUP should be BLESS. You argue that it
"doesn't do any blessing", ignoring Michael's point about PRINT not
(necessarily) doing any printing.
As you pointed out in the 'MIGRATION' section, such a radical change
to the meaning of DESTROY [w]ould have serious impact. I contend that
a name other than DESTROY should be chosen for recursive-destructor
role. I like CURSE, though maybe ABSOLVE will better please the
unperverted among us. Then object reblessing would naturally call
CURSE via the old package and BLESS with the new. If reblessing is
not itself condemned, that is.
use base map { "Base$_" } 1 .. 999;
{
my $x = bless {}; # a thousand blessings
}# a thousand curses (m+s vs refcounting aside)
=head2 The CSETUP method
It is proposed that, if a class has a method named CSETUP, that method
will be invoked automatically during any call to Cbless. It
is further proposed that Cbless be extended to take an optional argument
list after its second argument, and that this list would be passed to
any CSETUP method invoked by the Cbless.
Every base's SETUP gets the same argument list? That seems highly
undesirable from an OO-purity standpoint. Or do you have a syntax for
member initializer lists in store for us?
Better, have UNIVERSAL::new load the args into a hash and pass it to
SETUPs by reference, avoiding positional-parameter hell. SETUP can
delete what it processes and insert what its bases need.
UNIVERSAL::new can even warn about "unrecognized initializer arg" if
there's anything left in the hash when SETUPs have finished. See my
experimental UNIVERSALs below.
Note that CBase2::DESTROY is only called once (as late as possible),
even though class Rederived inherits it through two distinct paths.
Let's get the single-inheritance case nailed down before we think
about how it should work in MI. With Perl's interface inheritance (a
term for which I thank you, Damian), who knows? Maybe some base
classes don't want to be virtual.
=head2 Proposed standard CUNIVERSAL::new
Given that most Perl classes are hash-based and that the CSETUP method
cleanly separate construction and initialization, it might be desirable to
have the UNIVERSAL class always supply a default constructor:
package UNIVERSAL;
sub new { bless {}, @_ }
Yes, and it could call SETUP the way you want, eliminating the need to
change the 'bless' builtin. There could even be a UNIVERSAL::SETUP
that looks for args from %FIELDS (or its successor) in its initalizer
hash. Below is something along these lines that I put together last
year. It relies on pseudohash semantics, but the principles are
what's of interest.
package JTobey::UNIVERSAL;
sub new {
if (scalar(@_) =~ /[02468]$/) {
require Carp;
Carp::confess ("Missing value for last initializer");
}
my ($pkg, %args) = @_;
my ($obj, $fields);
{ no strict 'refs'; $fields = \%{"$pkg\::FIELDS"}; }
$obj = bless [$fields], $pkg;
$obj-init (\%args);
if (%args) {
require Carp;
Carp::croak ("Initializer list contains unrecognized fields: "
.join(", ", keys %args));
}
return $obj;
}
sub init {
my ($obj, $argsref) = @_;
my ($fields, $pos);
$fields = $$obj[0];
foreach my $name (keys %$argsref) {
next if not $pos = $$fields{$name};
$$obj[$pos] = delete $$argsref{$name};
}
}
# Break circular references.
sub free {
@ { $_[0] } = ();
}
-John
Re: RFC 188 (v1) Objects : Private keys and methods
Once a hash has been Cprivate-ized, the only way to extend its set of
entries is via another call to Cprivate:
sub new {
my ($class, %self) = @_;
bless private \%self, $class;
private $self{seed} = rand; # okay
$self{seed} = rand; # dies, can't autovivify
}
can we eliminate the private keyword and perform this check on all
blessed array/hash references? direct access to entries is prohibited
outside of the bless()ed package:
package MyAccount;
@ISA = qw(BaseClass);
sub new {
my $class = shift;
bless $class-SUPER::new(@_), $class;
}
sub creditBalance {
self-{balance} += shift; # valid
}
sub debitBalance {
self-{balance} -= shift; # valid
}
package main;
$acc = MyAccount-new;
$acc-{balance} *= 1000; # dies
just IMHO,
kenneth
Re: perl6-language-regex summary for 20000831
On Thu, Aug 31, 2000 at 12:34:05PM -0400, Mark-Jason Dominus wrote: perl6-language-regex Summary report 2831 RFC 72: The regexp engine should go backward as well as forward. (Peter Heslin) This topic did not attract much discussion until the very end of the week. I sent the author a detailed critique, to which he has not responded. As the author in question, I would like to note in my defense that there is only about 12 hours beween the timestamp of that critique and that of this message noting a lack of response. I posted a detailed response (within 24 hours) and have now posted a revised RFC. Peter
Re: RFC 184 (v1) Perl should support an interactive mode.
"Michael Maraist" [EMAIL PROTECTED] writes:
[...]
First, the current debugger allows multi-lines if you use "\" at the end of
the line ( a la C ).
Thanks. TomC also pointed this out. I still don't like it, though.
(But it will be added to the next revision).
Take a look at what sh will do for you:
$ while true; do
echo 'Infinite loop!'
done
Since you've not finished typing in a command, it keeps going until
you have.
Second, lexically scoped variables will dissapear on subsequent debugger
lines since their scope is wrapped in an eval.
The RFC mentions this, perhaps not prominently enough. The ability to
muck about with variable scopes on the command line is handy, though,
when you just want to test "what X does". You're right that since you
cannot exit the "global debugger scope", it is for the most part not
very useful. But it is desirable to have a command line which
imitates the language as much as possible.
For the most part, the
debugger is assuming that you're not using strict (and even if you did try
it, strictness would fall out of scope ).
Exactly. It should not.
Therefore there's little reason
for lexically scoped variables, except possibly for typed variables.. But
even then, that only benifits the development cycle, since you're arguably
not going to write massive code in a debugger. Currently scalar typeing
severs no real additional purpose, since pseudo-hashes (the closest you
currently get), work fine as long as the hash-prefix is present in the
array.
Benefiting the development cycle is exactly what I want to do. And if
I'm running Perl as a calculator, I'll write multi-line code. Even
today, for some massive "exploratory" file-munging I just type at the
debugger.
Next, there's something to be said for writing an entire function / for-loop
on a single line.. And that's easy history substitution. When you're in the
debugger, you're obviously trying to debug something. Which means trial and
error... Lots of it. I can't tell you how frustrating it is when I cut and
past code into a SQL or python prompt only to be reminded that I can't make
useful use of the history mechanism. Putting lots of code on one line means
you can up-arrow, Control-arrow over to the next attempted change, then hit
enter, very efficiently. The closest you can come in the other's is to open
an emacs window and cut / paste (which has it's advantages too).
Take a look at `zsh' (I should really add a REFERENCES section to the
next revision). This lets you edit your multi-line commands easily,
since the command line editor is a multi-line beast. There's even an
alias to edit text files using it floating around somewhere in the
documentation.
Next, learn a neat optimization:
perl -de 42
becomes:
perl -de0
You're just saying evaluate 0, or 42, or what-ever.. Which is just an
ignored op-code.
Yes. `42' is the officially approved value here, for unquestionable
reasons.
Next, it would be possible to extend the existing DBI module or create your
own (obviously a non-trivial task), then specify the new debugger on the
command line:
perl -d:debugger_name -e0
Now for the fun part. In order to achieve a truely interactive interpreter
like sh, xsql, python or lisp, you need the interpreter to be able to
understand the context of what you're typing. bash, for example, knows when
you have mis-matched quotes, or the here-document, and prompts you for more
text accordingly.
In perl, however, there is no easy way to parse perl.
perl can parse Perl, so there's no reason for its debugger to do so
again. I "just" want Perl to provide enough hooks into its parser to
allow it to parse multi-line commands in the debugger.
This has been it's
biggest hypocracy as far as I'm concerned.. I'm going to make an RFC for it.
I think somebody else is planning an RFC on accessing the parser.
Note, though, that this could require an extension to the parser
access beyond "just tell me if this string is a complete legal
command"; at the very least, you must know if all extensions of the
string are syntax errors. This is different from saying if the parse
succeeded: if you have Cdo {, it's a syntax error, but can be
extended to be a legal Perl form. But if you have Cdo }, it's a
syntax error no matter how you choose to extend it.
[...]
I often write configuration files for code. But I fear actually evaluating
configuration data (even in tainted mode). The end result is that I come up
with my own syntax which I parse with reg-exs. Sadly I find myself
reproducing the complexity of hashes / arrays needlessly. Ideally, I would
like to parse perl-like syntax but apply my own meaning to the parsed data.
Such an extension of the perl-parser could definately be applied to a
debugger..
This is a separate issue, which belongs in a separate RFC. The
debugger syntax should be as close as possible to the Perl syntax; any
extensions are probably
Re: RFC 175 (v1) Add Clist keyword to force list context (like Cscalar)
On Fri, 1 Sep 2000 13:25:07 +1100 (EST), Damian Conway wrote: More than anything I think the inability to write Csub list DWIMishly argues that we need it built-in. But we also need a *very* careful design of the semantics. Well, except that it isn't clear which DWIM you want. Does DWIM mean, the effect that you don't have if you drop that proposed keyword? It's the most powerful construct, but also very intransparent. I don't like that. Let's fall back to what we have already: $\ = "\n"; print $a = () = qw(a b c); -- 3 All those who expected that the list would be evaluated in array (not list!) context, raise your hands. Not many, I would think. -- Bart.
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
First is the choice of arrays verses hashes as the choice for set storage.
Arrays are obviously easier to construct, but hashes are both faster
implementations, and easier to determine membership.
Well in fact I'm interested by such functions in order to manipulate
lists
of scalars (1, 'toto') and to manipulate lists of hash table references
( { name = 'joe', age = 21 }, { name = 'sam', age = 27 } )
and I'd like to use these functions independantly of the array content
type.
Next, what subset of the set-theory should be implemented. Obviously you
refer to the basic and / or / xor, but in real practice, the other operators
can be very useful. Chaining operators (especially with array-based-sets)
can be a performance nightmare.
Well, the more functions will be implemented, the happiest I will be.
But in pratice I really often need Union, Intersection, Difference, In,
Not In.
This is the minimum for me.
Next, these operations can easily be implemented as a module (written out to
C if you like), and simply distributed with the core library.. Since some of
us are working to tighten down on the core of perl and break things out into
modules, this obviously runs counter to our goal.
Maybe this could be in a module.
But for me, these functions are so natural when manipulating arrays,
that it
seems normal they will be part of the language.
Even the odd form of passing two arrays to the function could still work
with a module through the use of prototypes ( sub union(\@\@) { ... } ).
Unfortunately, because of this, you would require that only true arrays can
be passed. I would much rather be able to instantiate a new set on the fly
as in:
@u_set = union( \@set_a, [ 1 ] );
Ok, for the call using references.
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
Gael Pegliasco wrote:
First is the choice of arrays verses hashes as the choice for set
storage.
Arrays are obviously easier to construct, but hashes are both faster
implementations, and easier to determine membership.
Well in fact I'm interested by such functions in order to manipulate
lists
of scalars (1, 'toto') and to manipulate lists of hash table references
( { name = 'joe', age = 21 }, { name = 'sam', age = 27 } )
and I'd like to use these functions independantly of the array content
type.
The point is that a hash of booleans (not a list of hashes) is a more direct
way to implement a set. A set is unordered, and does not have duplicates.
This is also true of hash keys. Furthermore, the nature of a hash makes it
faster and easier to check for the existance of a key, which is the
fundamental operation of a set (test for membership).
Re: RFC 184 (v1) Perl should support an interactive mode.
--On 31.08.2000 23:54 Uhr + Perl6 RFC Librarian wrote: This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Perl should support an interactive mode. Most of what you want is already implemented in the perl shell available at http://sourceforge.net/projects/psh/ -- Markus Peter - SPiN GmbH [EMAIL PROTECTED]
Re: Proposal: chop() dropped
I already proposed that. Benchmarks show that reading a file with explicit chomp() is easily 20% slower than reading the same file with implicit chomp(), through the -l command line switch. And what, pray tell, do you do about the small matter of wanting to read some files without implicit record-terminator deletion, and others with such? Or, for that matter, applying it to something other than the implicit ARGV reading from -n or -p? Seems like it should be a filehandle property. --tom
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
Gael Pegliasco wrote:
Yes, this is true, but the natural syntax, for me, to manipulate sets,
is the one of arrays.
It is not natural to write :
%my_fruit_set = ( 1 = 'orange', 2 = 'lemon' );
but it is natural to write :
@my_fruit_set = ( 'orange', 'lemon' );
I don't want to have to deal with keys of hashes because my set elements
don't care about them !
Adjust your thinking a bit, not the language. Try:
%my_fruit_set = (orange = 1, lemon = 1);
or
@my_fruit_set{qw/orange lemon/} = ();
Then you can query:
if (exists $my_fruit_set{orange}) # Is "orange" in the set?
delete $my_fruit_set{lemon} # Remove "lemon" member
@my_fruit_set{keys %his_fruits} = (); # Add members from another set
Hashes are random access -- like sets. Arrays are linear access.
Not like sets.
I suggest you find a copy of _Mastering Algoritms with Perl_,
by Orwant, Hietaniemi, and Macdonald, published by O'Reilly.
It has a good introductory chapter on how to represent sets
with perl hashes. It contains code -- most of it quite simple
and short -- for implementing union, intersection, complement,
etc, with hashes and with bit vectors.
Also, as TomC recommended, do check out the existing modules
on CPAN.
--
Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort
Senior Software Engineer'tona ', 'reh', 'ekca', 'lre',
Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';
Re: RFC 175 (v1) Add Clist keyword to force list context (like Cscalar)
Bart Lateur wrote: $\ = "\n"; print $a = () = qw(a b c); -- 3 All those who expected that the list would be evaluated in array (not list!) context, raise your hands. this illustrates why the whole subject is, or can be, so confusing. That qw() list was NOT evaluated in "array" context. It was eval'd in list context, just like we expect. The $a=3 comes from the overloaded behavior of the = assigning a list of values, but in a scalar context. And now it bothers me that I can't find this documented anywhere. It certainly isn't under the "=" entry in perlop. But I thought it was common knowledge... -- John Porter We're building the house of the future together.
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
At 03:40 PM 9/1/00 +0200, Gael Pegliasco wrote:
Arrays are ordered.
Hashes are not.
Neither are sets.
Arrays can have repetitions.
Hashes can not.
Neither can sets.
etc.
--tom
Yes, this is true, but the natural syntax, for me, to manipulate sets,
is the one of arrays.
It is not natural to write :
%my_fruit_set = ( 1 = 'orange', 2 = 'lemon' );
You are right, that is not natural. I don't know why I would ever want to
use a hash keyed using integers instead of arrays. But that's not how I
would use a hash for a set.
but it is natural to write :
@my_fruit_set = ( 'orange', 'lemon' );
I don't want to have to deal with keys of hashes because my set elements
don't care about them !
In a hash implementation, your hash keys -are- your set elements!
my %set;
# add elements to %set
$set{'elem1','elem2'} = 1;
# test for set memebership
print "elem1 in %set\n" if exists $set{'elem1};
# Compute union
$union{keys %set1, keys %set2} = 1;
# Compute intersection
for $elem (keys %set1) { $intersect{$elem} = 1 if exists($set2{$elem});}
# set difference
delete @set1{keys %set2};
How do you currently do these things with arrays?
so, I want new functions to manipulate arrays.
then, when manipulating arrays, without speaking about sets, you often
need in/union/intersection functions, even if arrays have duplicated
elements or if they are ordered.
Well, in fact I don't understand why you don't think that
union/intersection/difference are not usefull functions for arrays ?
Because I don't know what they will do with an array. They are
(reasonably) well defined for sets, but not for arrays.
Gael,
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
If it were possible to assign to the keys of a hash, we'd be
a lot closer to our ideal:
keys(%intersection) = map { exists $set1{$_} ? ( $_ = 1 ) : () } keysSNIP
but this is not currently legal perl.
keys %HASH = LIST;
is really
@HASH{ LIST } = ();
--tom
Re: RFC 175 (v1) Add Clist keyword to force list context (like Cscalar)
On Fri, 01 Sep 2000 07:30:54 -0600, Tom Christiansen wrote: % man perldata List assignment in a scalar context returns the number of elements produced by the expression on the right side of the assignment: $x = (($foo,$bar) = (3,2,1)); # set $x to 3, not 2 And not 1, either. $x = (($foo,$bar) = f()); # set $x to f()'s return count Does that answer your own previous question? To be consistent, "scalar list" should return the number of elements. -- Bart.
Re: the C JIT
Nathan Wiger wrote: "David L. Nicol" wrote: my dog $spot; to dog spot; If we only allow this where enough info is available to allocate dog-sized pieces of memory directly, Perl can blaze through the code that deals with dogs. I don't see what barewords gain us here. Who says that They gain us compliance with the whims of the people who like barewords for variable names. You may or may not find that to be a good thing. I like flexibility. We also gain a way of differentiating between a "Scalar" which refers to a "type" which is something else and a lot of very late binding, and a fixed-size object, an implementation detail that rfc 161 does not address. These fixed-size "external" objects would not subclass Scalar, and they could be easily differentiated if they were barewords. From a API point of view they are crippled scalars. -- David Nicol 816.235.1187 [EMAIL PROTECTED] Kansas City Perl Mongers will meet Sept. 20th at 7:00 in Westport Flea Market Bar Grill http://tipjar.com/kcpm
Re: the C JIT
Sam Tregar wrote: On Thu, 31 Aug 2000, David L. Nicol wrote: We're talking about making a faster Perl. C's syntax requires enough clarity to compile to something quick. it is a very short hop from my dog $spot; to dog spot; What about the second version would result in faster execution? Do you think that the "$" slows down Perl? Is it that dropping the "my" would make "spot" global and thus faster? What are you getting at? No, I imagine that dropping both the my and the $ would make spot a fixed-size stacked lexical, as it does in C. A speed increase would result from the code clarifier being able to resolve references to spot within the current and enclosed blocks as a fixed offset from a known pointer rather than five or six of those. Again: C doesn't get its speed from its syntax. Supporting C-esque syntax doesn't make Perl faster. C syntax and Perl syntax are mostly compatible in what is not a syntax error in the other. A lot of code is in C. Including it -- like, #include "somecode.c" has immense potential for re-use value. Supporting C semantics -- fixed offsets from a stack pointer instead of table lookups -- may very well make perl faster. -- David Nicol 816.235.1187 [EMAIL PROTECTED] Kansas City Perl Mongers will meet Sept. 20th at 7:00 in Westport Flea Market Bar Grill http://tipjar.com/kcpm
Re: proto-RFC: keys(HASH) as lvalue (was Re: RFC 179 )
On Fri, 1 Sep 2000 10:23:27 -0400, John Porter wrote:
keys %HASH = LIST;
is really
@HASH{ LIST } = ();
Sure. Would you have any great objection to adding the alternative syntax?
I have some doubts. See perlfunc -f keys, from which I quote:
If you say
keys %hash = 200;
then `%hash' will have at least 200 buckets allocated for
it--256 of them, in fact, since it rounds up to the next power
of two.
So, in summary: with this new syntax, you cannot safely distinguish
keys %hash = 200;
from
$hash{200} = undef;
--
Bart.
Re: proto-RFC: keys(HASH) as lvalue (was Re: RFC 179 )
Bart Lateur wrote: If you say keys %hash = 200; then `%hash' will have at least 200 buckets allocated for it--256 of them, in fact, since it rounds up to the next power of two. This should go away, of course. -- John Porter
Re: the C JIT
"David L. Nicol" wrote: They gain us compliance with the whims of the people who like barewords for variable names. You may or may not find that to be a good thing. It's not just that I don't think dropping $'s is a good idea, but that is the general consensus as well. I can't see dog spot; Ever getting into Perl realistically. For one thing, that already has strong meaning as: spot-dog; Because of the truly wonderful indirect object syntax. We also gain a way of differentiating between a "Scalar" which refers to a "type" which is something else and a lot of very late binding, and a fixed-size object, an implementation detail that rfc 161 does not address. These fixed-size "external" objects would not subclass Scalar, and they could be easily differentiated if they were barewords. From a API point of view they are crippled scalars. These types of distinctions are very valid, but again I think you're focusing too much on trying to create a whole new syntax to accomodate them. A new keyword or type or attribute is all you need: my int $spot : optimized = 5; var int $spot = 5; my fastint $spot = 5; Your ideas are good, I just think your implementation suggestions are not Perl. -Nate
Re: RFC 175 (v1) Add Clist keyword to force list context (like Cscalar)
for reality here. That should be written more like:
1 while FH; $burp = $.;
or even:
for ($burp = 0; my $line = FH; $burp++) {}
I'd go for
my $burp = 0; $burp++ while FH;
This proposal should be dropped.
I read your message and agree. Not that I liked the idea that much even
before considering the ramifications. But do you agree that even
seasoned perlers have trouble anticipating how a list/array is going to
be converted to a scalar?
I'd vote for no Clist operator, but for adding a count operator and a
last element operator. I suggest ()= for the first and Cpeek for the
second. I wouldn't mind if the first were spelled Ccount, either. Tom,
does this make sense, or am I confusing "lists" with "the comma operator
in parentheses" again?
And would we want a Cfirst to make shift/first, pop/peek?
One should eschew the temptation to write
() = FH; $burp = $.;
for the memory concerns given above.
I'd also vote for $burp = () = FH to be recognized by the optimizer,
just to encourage *all* counting to be done via ()=. It makes assigning
FH to () in scalar context a special case, but only to the optimizer,
and that's what an optimizer is there for -- optimizing special cases.
Or it could be extended to assigning FH to a finite-sized list, I
guess? Ack! Okay, I admit it, lvaluable list assignments make my head
hurt.
Re: RFC 175 (v1) Add Clist keyword to force list context (like Cscalar)
On Fri, Sep 01, 2000 at 11:23:16AM -0700, Steve Fink wrote: I read your message and agree. Not that I liked the idea that much even before considering the ramifications. But do you agree that even seasoned perlers have trouble anticipating how a list/array is going to be converted to a scalar? I would say the only place this is an issue is when the RHS is the return of a sub. You may not know if it was return (1,2,3) or return @a and there seems to be no standard way people document the difference. I'd vote for no Clist operator, but for adding a count operator and a last element operator. I suggest ()= for the first and Cpeek for the second. I wouldn't mind if the first were spelled Ccount, either. Tom, does this make sense, or am I confusing "lists" with "the comma operator in parentheses" again? perl already has a count operator, it is the only 4 charater non-alpha operator it has =()= :) Graham.
Re: RFC 114 (v2) Perl resource configuration
Can't you do this with with an environment setting? Shell people seem to think this a normal notion, but it's caused horrible security flaws in the past. And I couldn't imagine it of a C compiler, so I don't know why you would do this one. --tom
Re: RFC 175 (v1) Add Clist keyword to force list context (like Cscalar)
Tom Christiansen wrote:
First off, thanks for taking the time to present such a thorough
document. Well-reasoned arguments is exactly what the Perl 6 project
needs, IMO.
I read this early last night, and have been postulating on it ever
since. In the process of trying what feels like 100's of examples, I've
hit on some very interesting inconsistencies in Perl's list context.
Also, in the process I found an absolutely huge^Wenormous hole in the
RFC I wrote. Look at these examples:
$count = list split /!/; # easy
$count = () = split /!/; # not as easy
my($arg1) = func;# easy
my $arg1 = list func;# not as easy
There's absolutely no way any single operator could do both. For that
reason alone, consider the RFC as-written dropped. That's doesn't mean
the issue's dropped, just that the RFC's complete garbage.
However, let that not overshadow the points I'm about to make, because I
think they indicate fundamental problems with Perl's context engine. I'm
only going to address one of your examples, because they're all
fundamentally the same:
If you write
$burp = LISTIFY( grep {EXPR} @data );
What's in the burp?
By this argument, then why aren't these different?
@data = qw(this that and the other thing);
$x = @lines = grep /th/, @data;
$y = ($first, $second) = grep /th/, @data;
$z = () = grep /th/, @data;
print "$x, $y, $z"; # 5, 5, 5
If list() were to return something different than the above, then "()="
is not really a list constructor. Perhaps it's an array constructor? Of
special interest is the second one, which while appearing to set only
two values, actually creates a list (array?) of 5 somewhere. Then it
turns around and $y gets its length.
However, curiously, split() does *NOT* do the same thing:
$data = qq(this that and the other thing);
$a = @lines = split /\s+/, $data;
$b = ($first, $second) = split /\s+/, $data;
$c = () = split /\s+/, $data;
print "$a, $b, $c"; # 6, 3, 1
Whoa. That's bad. I don't care which way you look at it, but that's bad.
We have the same exact operators, but one constructs a true list while
the other constructs an array behind the scenes? Has anyone noticed this
before?
We need to choose one behavior or the other. This is not TMTOWTDI, it's
inconsistent and downright confusing. I'd be very surprised if anyone
doesn't consider this a bug, even if you understand why it happens.
If we want two separate behaviors, then we need two separate operators,
perhaps left-side [] to force a true array context, and left-side () to
force a true list context.
I just want to make one more point on your email before coming back to
this point:
If you write
$burp = LISTIFY( FH );
Then you have a potentially biggissimo temporary list in memory,
Yes, and this would be just as stupid as doing something like this:
$burp = () = FH;
Which you can do currently. So I think your point here is better taken
as "don't be an idiot", not really "list() is a bad thing".
As Damian has pointed out, there's some confusion about just what
this Csub list thing (which I, above, have written LISTIFY) would
look like.
Yes, and as the simple examples above showed, there's some serious
issues here with Perl 5's list context, IMO.
One example you didn't address was this:
foo( () = bar() );
This, more than any others, is the one that drives me batty. It seems
the solution for this to me is:
1. Always have bar() interpreted as a list context
2. Let foo()'s prototype specify arg1 as $ if it
wants a scalar
That's certainly the most useful behavior that I can see. And if I just
wanted to force the scalar then I could use:
foo( scalar bar() );
As far as I can tell through my examples, this is pretty much what
happens now. So it might be worth just clarifying this concept.
I would gladly drop the list() idea entirely if (a) we fix the broken
stuff and (b) clarify what we're doing with chained subs so the above
foo() example never has to be used again.
-Nate
Re: RFC 56 (v3) Optional 2nd argument to Cpop() and Cshift()
On Fri, Sep 01, 2000 at 08:38:18PM -, Perl6 RFC Librarian wrote: =head1 IMPLEMENTATION I don't know the gory details other than it should be possible. Thinking in perl5 terms, its going to require a modification to pp_pop and pp_shift. The simplest way to do it would be for them to simply call pp_splice if a second argument is given and its greater than 1. No second argument and 1 are treated as a normal pop()/shift(). Possibly also opcode.pl and ck_shift() in op.c would need to be modified to account for the new syntax. However, there is one implementation detail that occurs to me: What should happen when the expression given to Cpop(), or Cshift() evaluates to a negative number? I see three options: 1) Nothing. We can only pop/shift positive amounts 2) Act as if the number were positive (i.e. pop @array, abs(EXPR)) 3) Cpop() would then act as Cshift() and Cshift() would act as Cpop() If pop @array, -1 == shift @array, 1 and shift @array, -1 == pop @array, 1, and if both Ways To Do It are almost exactly the same, then there's no value to allowing negative numbers. In most cases I'd expect passing a negative number to be a mistake on the programmer's part. #2 is very bad. Silently correcting a mistake just leads to uncaught bugs. #3 I do not like for the same reasons as #2. Accidentally typing a negative number of pop()s shouldn't silently revert to a shift and vice-versa. It doesn't add any functionality and its not a particularly different or interesting way to do it. #1 is good, assuming it causes an error. It also leaves open the possibility of reverting to #3 at some later date. And pop(@array, 0) should do nothing and produce a warning. Garbage In/Error Out. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse GuRuThuG make a channel called Perl, and infest it with joking and funit doesnt make alot of sense.
Re: RFC 56 (v3) Optional 2nd argument to Cpop() and Cshift()
Michael G Schwern wrote: If pop @array, -1 == shift @array, 1 and shift @array, -1 == pop @array, 1, and if both Ways To Do It are almost exactly the same, then there's no value to allowing negative numbers. In most cases I'd expect passing a negative number to be a mistake on the programmer's part. I'd like to see negative numbers work. Otherwise the programmer would have to explicitly check whether an index into a string was positive or negative, take the absolute value, and use pop() or shift() as appropriate.
Re: RFC 59 (v2) Proposal to utilize C* as the prefix to magic subroutines
Let's take an example...
sub *DESTROY {
# Perl-special
}
How would you call this manually, as you sometimes want to do?
*DESTROY $self;
$self-*DESTROY;
So you'd have to redo Perl's parsing of *? Would this override
typeglobs? How would the precedence work? The RFC should address this.
If you want to do this, then I suggest you make the RFC address all the
Perl-special variables too, such as:
@*INC
%*ENV
$*SIG{INT} = \catch_sig;
Since these chew up namespace too. Just renaming half a dozen subs has
little value-add. Renaming all Perl-special stuff makes it more
consistent.
I'm against the RFC. But I'm just pointing out, if you're going to make
Perl-special stuff look different, then you have to make *ALL*
Perl-special stuff look different, otherwise the language will be marred
with inconsistencies.
Don't forget about Perl classes like *CORE:: and *UNIVERSAL:: too. This
RFC is not just a simple change if you want it to be worthwhile.
-Nate
Re: RFC 114 (v2) Perl resource configuration
Forcing -w on Makes one-liners annoying. Makes running existing programs annoying. We have PERL5OPT You forgot the con that we've supposed to be "use warnings"-ing now. --tom
Re: RFC 114 (v2) Perl resource configuration
"MGS" == Michael G Schwern [EMAIL PROTECTED] writes: MGS Here's a little pros/cons list running through my head right now... MGS pro con MGS Customize @INC We have PERL5LIB MGS Forcing -T on Will break most existing programs. MGS Makes one-liners annoying. who runs one liners with -T? what about making the rc files load only if there is code not in a -e string? this solves the one liner problem. you can force them with another option if you want them with -e. i can't imagine why you would but there are crazies everywhere. MGS Furthermore, .perlrc files can currently be implemented without a core MGS patch. Write a script which looks for a .perlrc file, generates a bit MGS of perl code, prefixes this to the program being run and then passes MGS it all to perl. Put that in place of /usr/bin/perl and tada! We MGS could develop such a script and distribute it with Perl. Such a MGS script also makes a good prototype, to hash out the pros and cons of MGS this RFC should anyone want to go forward with it. yechhh!! and that script will slow everything down with a double call to perl. i think a system rc file is a good idea but the way to use it is not well defined. i think an environment var might be a good way. if it is set, it is the file(s) to preload before running your code. export PERL_PRELOAD=/etc/sysperl:/home/uri/.perlrc perl foo simple, out of the way if you don't need it. on any site where the admins like to control stuff this way, they already preset many env values for you in the shared shell startup files. adding one more value would be trivial. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: RFC 114 (v2) Perl resource configuration
i think an environment var might be a good way. if it is set, it is the file(s) to preload before running your code. You've got PERL5OPT. Heck, I bet you could do a cleverness with .perldb, too. :-) --tom
Re: RFC 114 (v2) Perl resource configuration
On Fri, Sep 01, 2000 at 07:16:13PM -0400, Uri Guttman wrote: "MGS" == Michael G Schwern [EMAIL PROTECTED] writes: MGS Forcing -T on Will break most existing programs. MGS Makes one-liners annoying. who runs one liners with -T? That's the point. .perlrc would effect all perl, including one-liners. What's good for big programs is not good for small. what about making the rc files load only if there is code not in a -e string? this solves the one liner problem. I thought of this, but the special cases begin to pile up. First, there's the issue of Perl acting differently from a file as from a command line. Weird. Then in the .perlrc there's something things you'll want for one-liners, some for files, some for both. Sounds like it would make writing the .perlrc files hairy. And there's still the problem of .perlrc not being down with OPP (Other People's Perl). yechhh!! and that script will slow everything down with a double call to perl. Not necessarily. It could eval() instead. A prototype can be written and performace testing performed before we start declaring things slow. It will probably slow things down a bit, yes, but that has to be weighed against the *signifcantly* simpler implemetation than a core patch. Especially considering the low urgency of this RFC. i think a system rc file is a good idea but the way to use it is not well defined. i think an environment var might be a good way. if it is set, it is the file(s) to preload before running your code. The question still remains unanswered. What do you DO with a .perlrc file?? -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse I am not one of those stupid moron who don't know what I am doing. I know about FDA. FDA raids hundreds of small businesses every year that deal with alternative medicine or therapy. They take away your computer, seize your $200,000 inventory, and drive your company totally out of business in no time if they ever approach you. --Alex Chiu, Immortality Guy
Re: RFC 114 (v2) Perl resource configuration
"TC" == Tom Christiansen [EMAIL PROTECTED] writes: i think an environment var might be a good way. if it is set, it is the file(s) to preload before running your code. TC You've got PERL5OPT. but that is the user's to set. PERL_PRELOAD allows the admin to globally set (in the system shell rc file) the rc files that perl will load. it needs to be separate from the env vars the user might want to set. TC Heck, I bet you could do a cleverness with .perldb, too. :-) i don't want to go there. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: RFC 114 (v2) Perl resource configuration
but that is the user's to set. PERL_PRELOAD is there for the user to unset. allows the admin to globally set (in the system shell rc file) the rc files that perl will load. And what sorts of things might the admin care to globally set? --tom
Re: RFC 114 (v2) Perl resource configuration
On Fri, Sep 01, 2000 at 07:42:32PM -0400, Uri Guttman wrote: "TC" == Tom Christiansen [EMAIL PROTECTED] writes: i think an environment var might be a good way. if it is set, it is the file(s) to preload before running your code. TC You've got PERL5OPT. but that is the user's to set. PERL_PRELOAD allows the admin to globally set (in the system shell rc file) the rc files that perl will load. Like any other environment variable which the admin wants to be everywhere, put it in /etc/profile. A well configured system will handle it from there. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse BOFH excuse #405: Sysadmins unavailable because they are in a meeting talking about why they are unavailable so much.
Re: RFC 114 (v2) Perl resource configuration
"MGS" == Michael G Schwern [EMAIL PROTECTED] writes: who runs one liners with -T? MGS That's the point. .perlrc would effect all perl, including MGS one-liners. What's good for big programs is not good for small. what about making the rc files load only if there is code not in a -e string? this solves the one liner problem. MGS I thought of this, but the special cases begin to pile up. First, MGS there's the issue of Perl acting differently from a file as from a MGS command line. Weird. Then in the .perlrc there's something things MGS you'll want for one-liners, some for files, some for both. Sounds MGS like it would make writing the .perlrc files hairy. well, special cases are perl's middle name. i know we want to lower then for 6 but this makes some sense. i don't want any preloaded stuff for my one liners. if i did, i would add the -R (or whatever) option to force them. as for the special case, it is easy to see the source is from -e and it won't slow anything down. i think an environment var might be a good way. if it is set, it is the file(s) to preload before running your code. MGS The question still remains unanswered. What do you DO with a MGS .perlrc file?? i wasn't trying to answer that, just come up with a clean way to support this feature. i don't know of a reason for me to use it but i am sure it will be used. it can be used for system specific @INC paths without recompiling perl, enforcing strict/-w/-T on all scripts, etc. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: RFC 114 (v2) Perl resource configuration
On Fri, Sep 01, 2000 at 07:42:32PM -0400, Uri Guttman wrote: "TC" == Tom Christiansen [EMAIL PROTECTED] writes: i think an environment var might be a good way. if it is set, it is the file(s) to preload before running your code. TC You've got PERL5OPT. but that is the user's to set. PERL_PRELOAD allows the admin to globally set (in the system shell rc file) the rc files that perl will load. Like any other environment variable which the admin wants to be everywhere, put it in /etc/profile. A well configured system will handle it from there. Not all shells -- nor shell invocations -- attend to that file. A shell is ``privileged'' if the -p option is used or if the real user ID or group ID does not match the effective user ID or group ID (see getu- id(2) and getgid(2)). A privileged shell does not process $HOME/.profile nor the ENV parameter (see below). Instead, the file /etc/suid_profile is processed. Clearing the privileged option causes the shell to set its ef- fective user ID (group ID) to its real user ID (group ID). If the basename of the name the shell is called with (i.e., argv[0]) starts with `-' or if the -l option is used, the shell is assumed to be a login shell and the shell reads and executes the contents of /etc/profile and $HOME/.profile if they exist and are readable. This is clearly for login shells only; that is, interactive work. Which is what .perldb does. :-) But still, I'm not clear on what to do with it. --tom
Re: RFC 114 (v2) Perl resource configuration
it can be used for system specific @INC paths without recompiling perl That's what PERL5LIB is for. enforcing strict/-w/-T on all scripts, etc. How are you going to enable -T from this file you're going to eval? How are you going to enable strict in an unrelated lexical scope? Why are you using -w instead of use warnings, and can you just imagine the howling? This would surely kill your system. --tom
Re: RFC 56 (v3) Optional 2nd argument to Cpop() and Cshift()
On Sat, Sep 02, 2000 at 09:42:09AM +1100, Jeremy Howard wrote: I'd like to see negative numbers work. Otherwise the programmer would have to explicitly check whether an index into a string was positive or negative, take the absolute value, and use pop() or shift() as appropriate. This has to be done now, unless you use splice(). I've never had it get in my way or had a situation where I needed to swap pop() and shift(). Has anyone else? -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse But why? It's such a well designed cesspool of C++ code. Why wouldn't you want to hack mozilla? -- Ziggy
Change ($one, $two)= behavior for optimization? (was Re: RFC 175 (v1) Add Clist keyword to force list context (like Cscalar))
Tom Christiansen wrote: % man perlfunc ... When assigning to a list, if LIMIT is omitted, Perl supplies a LIMIT one larger than the number of variables in the list, to avoid unnecessary work. As usual I picked a bad example. And I did read the perlfunc manpage, but somehow both (a) forgot about split's 3rd argument and (b) missed it on the rereading. This was example number 100+ on my list, so I was feeling a little woozy. RTFM. This is documented behavior. I don't understand the hubbub. Yeah, oops. Sorry for wasting bandwidth. sound of self-flogging Let me shift gears and instead ask whether anyone thinks this: $y = ($first, $second) = grep /$pat/, @data; Returning "5" has any value? If you're going to do this, it seems like you'd want the number that were really returned (since scalar grep will give you the total number found anyways). If so, then generalizing split's behavior to return smaller lists when they're requested might make things faster. In particular, grep could potentially stop much sooner if you only wanted the first two matches, and @data was 20,000 elements. If this was extended to user subs, Perl could actually DWIM speed improvements if the sub was building a huge list only to want the first few elements back. The only potential problem I see is that "=()=" would always return 0 now, since it has no elements it's asking for. Hmm. Maybe "=()=" could be special-cased to mean an infinitely hungry list, which is pretty much what it means right now. Anyways, just an idea. -Nate P.S. Consider list() a dead horse for now. No additional flogging required.
Re: RFC 114 (v2) Perl resource configuration
On Fri, Sep 01, 2000 at 05:49:05PM -0600, Tom Christiansen wrote: On Fri, Sep 01, 2000 at 07:42:32PM -0400, Uri Guttman wrote: Like any other environment variable which the admin wants to be everywhere, put it in /etc/profile. A well configured system will handle it from there. Not all shells -- nor shell invocations -- attend to that file. Yeah, well, that's not my problem that people don't use the One True Shell. ;) Actually, there is a utility out there for universal shell configuration. I've forgotten what its called, though. :( -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse BOFH excuse #116: the real ttys became pseudo ttys and vice-versa.
Re: RFC 114 (v2) Perl resource configuration
On Fri, Sep 01, 2000 at 05:50:52PM -0600, Tom Christiansen wrote: Why are you using -w instead of use warnings, and can you just imagine the howling? This would surely kill your system. Okay, okay, okay. You're the nth person that brought that up. Yes, "use warnings" makes more sense than -w. Same general problems all 'round. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse MORONS!
RE: RFC 114 (v2) Perl resource configuration
I entreat you to explain to me *anything* that you'd want to tweak with this that you already can't do right now. When I need to move Perl files from a default location to a new one. For example messing with @INC (and its like). THis could be used for example on a machine that has both development and production work going on.
Re: Change ($one, $two)= behavior for optimization? (was Re: RFC 175 (v1) Add Clist keyword to force list context (like Cscalar))
Let me shift gears and instead ask whether anyone thinks this: $y = ($first, $second) = grep /$pat/, @data; Returning "5" has any value? If you're going to do this, it seems like you'd want the number that were really returned (since scalar grep will give you the total number found anyways). Of course: the LHS is a known quantity; only the RHS is a mystery. That's why it does this. I'm sure this in perldata. --tom
Re: RFC 114 (v2) Perl resource configuration
I entreat you to explain to me *anything* that you'd want to tweak with this that you already can't do right now. When I need to move Perl files from a default location to a new one. For example messing with @INC (and its like). THis could be used for example on a machine that has both development and production work going on. That's a fine answer, but a completely different concern. @INC is trival. "And its like" are things you'll never get at! Look at the paths in Config. A trivial grep produces these, at least some of which I'm sure you want to change. You can't. Why not? Various reasons, but the most salient one is that they are not tweakable from Perl itself. And even if they were, they're wedged into a zillion different places--such as, just to name one example, the #! lines that head what gets stuck in scriptdir. --tom archlibexp='/usr/local/lib/perl5/5.6.0/OpenBSD.i386-openbsd' ccflags='-fno-strict-aliasing -I/usr/local/include' cppflags='-fno-strict-aliasing -I/usr/local/include' dynamic_ext='B ByteLoader DB_File Data/Dumper Devel/DProf Devel/Peek Fcntl File/Glob GDBM_File IO IPC/SysV NDBM_File ODBM_File Opcode POSIX SDBM_File Socket Sys/Hostname Sys/Syslog attrs re' extensions='B ByteLoader DB_File Data/Dumper Devel/DProf Devel/Peek Fcntl File/Glob GDBM_File IO IPC/SysV NDBM_File ODBM_File Opcode POSIX SDBM_File Socket Sys/Hostname Sys/Syslog attrs re Errno' installarchlib='/usr/local/lib/perl5/5.6.0/OpenBSD.i386-openbsd' installprivlib='/usr/local/lib/perl5/5.6.0' libpth='/usr/local/lib /usr/lib' prefix='/usr/local' privlibexp='/usr/local/lib/perl5/5.6.0' startsh='#!/bin/sh' aphostname='/bin/hostname' archlib='/usr/local/lib/perl5/5.6.0/OpenBSD.i386-openbsd' bin='/usr/local/bin' binexp='/usr/local/bin' config_arg0='./Configure' full_ar='/usr/bin/ar' full_csh='/bin/csh' full_sed='/usr/bin/sed' glibpth='/usr/shlib /usr/lib/large /lib /usr/lib /usr/lib/386 /lib/386 /lib/large /usr/lib/small /lib/small /usr/ccs/lib /usr/ucblib /usr/local/lib ' groupcat='cat /etc/group' hostcat='cat /etc/hosts' inc_version_list='5.00554/OpenBSD.i386-openbsd 5.00554 5.005/OpenBSD.i386-openbsd 5.005' inc_version_list_init='"5.00554/OpenBSD.i386-openbsd","5.00554","5.005/OpenBSD.i386-openbsd","5.005",0' installbin='/usr/local/bin' installman1dir='/usr/local/man/man1' installman3dir='/usr/local/man/man3' installprefix='/usr/local' installprefixexp='/usr/local' installscript='/usr/local/bin' installsitearch='/usr/local/lib/perl5/site_perl/5.6.0/OpenBSD.i386-openbsd' installsitebin='/usr/local/bin' installsitelib='/usr/local/lib/perl5/site_perl/5.6.0' installstyle='lib/perl5' known_extensions='B ByteLoader DB_File Data/Dumper Devel/DProf Devel/Peek Fcntl File/Glob GDBM_File IO IPC/SysV NDBM_File ODBM_File Opcode POSIX SDBM_File Socket Sys/Hostname Sys/Syslog Thread attrs re' lddlflags='-Bshareable -L/usr/local/lib' ldflags=' -L/usr/local/lib' libc='/usr/lib/libc.so.23.1' libsdirs=' /usr/local/lib /usr/lib' libsfound=' /usr/local/lib/libgdbm.a /usr/lib/libm.a /usr/lib/libc.a' libspath=' /usr/local/lib /usr/lib' lns='/bin/ln -s' locincpth='/usr/local/include /opt/local/include /usr/gnu/include /opt/gnu/include /usr/GNU/include /opt/GNU/include' loclibpth='/usr/local/lib /opt/local/lib /usr/gnu/lib /opt/gnu/lib /usr/GNU/lib /opt/GNU/lib' man1dir='/usr/local/man/man1' man1direxp='/usr/local/man/man1' man3dir='/usr/local/man/man3' man3direxp='/usr/local/man/man3' pager='/usr/bin/less' passcat='cat /etc/passwd' perl5='/usr/local/bin/perl' perlpath='/usr/local/bin/perl' prefixexp='/usr/local' privlib='/usr/local/lib/perl5/5.6.0' ranlib='/usr/bin/ranlib' scriptdir='/usr/local/bin' scriptdirexp='/usr/local/bin' sh='/bin/sh' sitearch='/usr/local/lib/perl5/site_perl/5.6.0/OpenBSD.i386-openbsd' sitearchexp='/usr/local/lib/perl5/site_perl/5.6.0/OpenBSD.i386-openbsd' sitebin='/usr/local/bin' sitebinexp='/usr/local/bin' sitelib='/usr/local/lib/perl5/site_perl/5.6.0' sitelib_stem='/usr/local/lib/perl5/site_perl' sitelibexp='/usr/local/lib/perl5/site_perl/5.6.0' siteprefix='/usr/local' siteprefixexp='/usr/local' src='/usr/local/src/perl-5.6.0' startperl='#!/usr/local/bin/perl' strings='/usr/include/string.h' sysman='/usr/share/man/man1' timeincl='/usr/include/sys/time.h ' usrinc='/usr/include' xlibpth='/usr/lib/386 /lib/386'
Re: RFC 114 (v2) Perl resource configuration
What I am thinking of is a file that, if present and sane (i.e. read-only root), would be involked by the interpreter just before the users script was parsed. Looking at your example of things in the config file, well some of those are the things I would like to be able to get at in the new version with this feature. Well, those are all things that are beyond the scope of what can be done with a little eval. And some are very difficult: they're interdependent, and sometimes already written out to disk somewhere or other. I do not see an RFC about the matter, but people certainly have requested to be able to have a "position independent" perl installation, one which they can just copy and move to random places and things still work. I do not know the status of that want. --tom
Quantum computing
Can't quite run perl yet. http://www.tomshardware.com/cpu/00q3/000901/index.html
RFC 59 (v2) Proposal to utilize C* as the prefix to magic subroutines
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Proposal to utilize C* as the prefix to magic subroutines
=head1 VERSION
Maintainer: Jonathan Scott Duff [EMAIL PROTECTED]
Date: 7 Aug 2000
Last-Modified: 1 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
Number: 59
Status: Developing
=head1 ABSTRACT
Perl has always claimed the ALL-CAPS names for itself, I propose we
give them back to the programmer.
=head1 DESCRIPTION
Perl steals subroutine names from the programmer. By prefixing the
Perl-special subroutines with a character that is not a valid prefix
for Perl programmers, we separate what belongs to Perl and what
belongs to the user.
With the proliferation of special subroutine names (BEGIN, END, INIT,
CHECK, etc.) the all capital subroutine names available to the
programmer has steadily shrunk. Rather than stealing subroutines from
the programmer, we should create a space just for Perl.
sub *BEGIN {
# do compile-time stuff
# Perl-special
}
sub BEGIN {
# No relation to the former. Purely user space.
# The user may have his/her own reasons for naming his
# subroutines this way. (e.g., it fits the conception model
# that the software is build upon/around/through)
}
The visual distinction lets the programmer know that something special
is happening here and that this is not your average run-of-the-mill
subroutine. The added C* prefix also serves as a guide to the perl
compiler that these subroutines may be treated specially.
Another area where could be useful is in conjunction with Damian
Conway's Cwant() proposal. As his proposal currently stands, the
programmer can not name a package LIST or SCALAR and use it with the
proposed Cwant(). Perl has always claimed all lowercase package
names for itself, but never ALLCAPS package names.
=head2 Examples
switch ([want]) {
case '*LIST'{ return @array; }
case '*SCALAR' { return $foo; }
case 'LIST' { return $MyListObj; }
}
sub *BEGIN { ... }
sub *END{ ... }
sub *INIT { ... }
sub *AUTOLOAD { ... }
sub *TIESCALAR { ... }
sub *FETCH { ... }
=head2 Potential problems
Makes Perl-special subroutines different from user subroutines. This
implies yet another special case.
=head1 IMPLEMENTATION
Um ... that's up to the internals people.
=head1 REFERENCES
Perl 5.6.0 documentation
RFC 21 (v1): Replace Cwantarray with a generic Cwant function
RFC 114 (v2) Perl resource configuration
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Perl resource configuration
=head1 VERSION
Maintainer: Jonathan Scott Duff [EMAIL PROTECTED]
Date: 16 Aug 2000
Last-Modified: 1 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
Number: 114
Status: Developing
=head1 ABSTRACT
Perl should provide a mechanism to have code automatically loaded from a
file upon interpreter startup.
=head1 DESCRIPTION
Many programs have so-called "resource configuration" files (at least
that's what I call them) that are loaded and executed upon program
startup. Some example programs that have this ability include bash,
mutt, and python. Perl should do something similar.
The first version of this RFC proposed two "rc" files: C/etc/perlrc and
C~/.perlrc [1]. However, the author of this RFC has decided that the
motivations behind C/etc/perlrc are misguided. If the administrator
of the system wishes to impose global behavior, he can and should do
so through the environment.
This RFC now proposes that Perl 6 support a single per-user "rc" file,
C~/.perlrc, that is loaded for each Perl program run by the user.
This file would simply be Perl code that is loaded and executed just as if
the following were at the top of each perl program executed by the user:
BEGIN { $_ = "$ENV{HOME}/.perlrc"; require if -e; }
Execution of the C~/.perlrc would not be the default behavior.
A command line switch would be needed to invoke the automatic loading.
For example:
#!/usr/bin/perl -r
# ~/.perlrc is now loaded
Thus the C~/.perlrc file could be used by the user to setup common
defaults such as diagnostics or stricture for all of his/her programs.
Also, if RFC 184 (interactive mode for perl) is adopted, it may be
desirable to automatically execute the contents of C~/.perlrc upon
entered an interactive session regardless of whether or not the
command line switch that triggers loading of C~/.perlrc was used.
Nathan Wiger [EMAIL PROTECTED] brought up the issue of packaging a perl
program and/or module that may rely on settings in the local C~/.perlrc
which could be radically different from the settings in the C~/.perlrc
on the client's side. It is suggested that a warning be emitted (if
warnings are turned on) when the programmer uses the command line option
to the the "rc file". How do the other programming languages that have an
"rc file" concept handle this problem (e.g., python)?
=head1 IMPLEMENTATION
An option would need to be added to explicitly make perl look for the
C~/.perlrc file. The author of this RFC tentatively suggests C-r.
=head1 MIGRATION
Only those programs that wish to take advantage of this feature need
translating from Perl5. This is best left to the programmer rather
than an automated translator.
=head1 NOTES
[1] Note that this RFC is couched in terms of a Unix-ish filesystem. Perl
should support the analogous concept for the other platforms on which
it compiles.
=head1 REFERENCES
Perl 5.6.0 Documentation
From the man page for python 1.6
bash documentation:
http://www.gnu.org/manual/bash/html_chapter/bashref_5.html#SEC61
The mutt man page: http://www.mutt.org/doc/man_page.html
RFC 184: Perl should support an interactive mode:
http://www.mail-archive.com/perl6-language@perl.org/msg02493.html
RFC 56 (v3) Optional 2nd argument to Cpop() and Cshift()
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Optional 2nd argument to Cpop() and Cshift() =head1 VERSION Maintainer: Jonathan Scott Duff [EMAIL PROTECTED] Date: 7 Aug 2000 Last-Modified: 1 Sep 2000 Version: 3 Mailing List: [EMAIL PROTECTED] Number: 56 Status: Developing =head1 ABSTRACT The inverse operations to Cpop() and Cshift() both accept a LIST to "add" to an array, yet Cpop() and Cshift() only remove Bone element from an array. In the interest of symmetry and TMTOWTDI, Cpop() and Cshift should allow the programmer to remove multiple items from an array. =head1 DESCRIPTION The intent should be obvious, but I'll point it out anyway. =head2 pop The documentation for Perl 5.6.0 states that pop has one of two forms: Cpop ARRAY, or just Cpop. This RFC proposes that a third form be added to Cpop() =over 4 =item pop ARRAY, EXPR EXPR would be evaluated to determine the number of elements to remove from the end of ARRAY and that number would be removed and returned. Thus Cpop() would be a more natural inverse to Cpush() (If you can add multiple elements to an array with Cpush(), why can't you remove multiple elements from an array with Cpop?) =back This functionality can currently be accomplished with Csplice(), but it is non-obvious that Csplice() should be the routine to call and the method isn't at all intuitive. To "pop" the last $N items off of the end of an array using Csplice(), the call looks like this: splice @array, -$N; # remove the last $N items contrast to the more natural looking pop @array, $N; # remove the last $N items Aaron J Mackey [EMAIL PROTECTED] asked whether or not this should really be equivalent to: reverse splice @b, -$N; # As if we'd popped each individually I think that the following should hold: @a = pop @b, $n; push @b, @a;# @b now in its original state. Thus, the 2 argument version of Cpop() should treat the C$N elements as a group. =head2 shift The semantics for Cshift() are similar to Cpop() except that it operates on the other end of the array. Cshift() also suffers from the inability to shift more than one element from the array. Just like Cpop(), the two forms of Cshift() are a Cshift ARRAY, and just plain Cshift. This RFC proposes that a third form be added: =over 4 =item shift ARRAY, EXPR EXPR would be evaluated to determine the number of elements to remove from the beginning of ARRAY and that number would be removed and returned. Thus, Cshift() would be a more natural inverse to Cunshift. (If you can add multiple elements to an array with Cunshift(), why can't you remove multiple elements with Cshift()?) =back As with Cpop() the proposed semantics can be accomplished with Csplice() and are just as un-intuitive: splice @array, 0, $N; # remove the first $N elements contrast to shift @array, $N; # remove the first $N elements Again, as with Cpop(), Cshift() should treat the first $N elements of the C@array as a group so that the following holds: @a = shift @b, $N; # remove the first $N elements unshift @b, @a; # put them back # @b is unchanged =head2 Random examples @numbers = 1..10; $ten = pop @numbers;# still works @popped = pop @numbers, 3; # Take away 7, 8, 9 push @numbers, @popped; # Put 'em back @popped = pop @numbers, 0; # Nothing happens @popped = pop @numbers, 9; # And then there were none. @numbers = 1..10; @popped = pop @numbers, 100;# And then there were none but # @popped only has 10 things @numbers = 1..10; $one = shift @numbers; # still works @shifted = shift @numbers, 3; # Take away 2, 3, and 4 unshift @numbers, @shifted; # Put 'em back @shifted = shift @numbers, 0; # Nothing happens @shifted = shift @numbers, 9; # And then there were none. @numbers = 1..10; @shifted = shift @numbers, 100; # And then there were none but # @shifted only has 10 things =head1 IMPLEMENTATION I don't know the gory details other than it should be possible. However, there is one implementation detail that occurs to me: What should happen when the expression given to Cpop(), or Cshift() evaluates to a negative number? I see three options: 1) Nothing. We can only pop/shift positive amounts 2) Act as if the number were positive (i.e. pop @array, abs(EXPR)) 3) Cpop() would then act as Cshift() and Cshift() would act as Cpop() I propose that option #3 be adopted since it seems the most Perlian and so far no one has disagreed. :-) =head1 MIGRATION Gisle
