Cya dudes
I tried to contribute on this list but it seems we've coalesced downto Tom and a handful of others. No one else has a voice. I have nothing but respect for Tom, Nathan, et al, but its no longer my idea of a community - more like a faction. I'm getting more into PHP now and less into Perl, only because PHP evolution seems to be acccelerated by novelty, and not mired into a few people's ideas. The politics of Perl are: A Suggestion... Did Tom or Larry or Uri or someone we all know make it? Yes? Unfold into myriad threads about the wonder of the idea.. No? Don't respond to it, its unworthy.. Nothing but respect for all of you here, and particularly those who I met in Monterray this year at Open Source. I just want to move into an arena of ideas, and not politics. I'll still use Perl but only as my secondary scripting now. PHP is my future because the little guy still has a voice. Sorry to make that statement as I committed so much time and effort to Perl and it's community, but I think, in the end, its only a place where genius has a voice. Sometimes good ideas come out of the masses and litle guys like me. I was good enough to complete 2 graduate programs at State universities in Comp Sci, and I suppose I ought to be good enough to be heard by a programming community. PHP listens, Perl talks. Again, sorry, -Ed _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com.
scalars vis-a-vis non-scalars
These would be perlish, nice, terse, succint, and economical: my ($a, $b, $c) = 0; @h(@colours)='red'; ($i, $i, $k) += 2; @nums = 10 * @nums; . . . Ed _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com.
an RFC for unbalanced parens/braces?
Since there were no objections to cleaning up the error messages on unbalanced parens and braces, can we RFC that request? -Ed _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com.
Can we improve the missing paren error message?
use diagnostics; my $i=1; print 'hi' if ($i=1; running this with perl -wc (v 5.004, unix), I get perl -wc x.pl syntax error at x.pl line 3, near "1;" x.pl had compilation errors (#1) (F) The final summary message when a perl -c fails. Uncaught exception from user code: x.pl had compilation errors. If I'm missing a "}" the compiler tells me its missing. That's also a syntax error, but it reports the actual missing "}". Why not do the same for ")"? In this simple case its easy to spot, but with thousands of possible "syntax errors" its not always this easy. I've learned from experience that usually this message implies a missing ")", at least for me, but why not explicitly state it? The compiler should provide as much error detail as possible, particularly if using -w and "use diagnostics". -Ed _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com.
reversable foreach ()?
I really like
(do something) if (something is TRUE);
as opposed to
if (something is TRUE) {do something}
Just personal taste I guess, but to me the former is a nice Perlism.
So what about
(do something) foreach (some list);
i.e.
print foreach (@l);
as opposed to
foreach (@l) {print}
Just a thought..
-E
_
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Share information about yourself, create your own public profile at
http://profiles.msn.com.
Fwd: RE: $a in @b
The fact that something can be accomplished in Perl doesn't necessarily mean
its the best or most desirable way to do it. I respect the programming
abilities, but
grep { ref($a) eq ref($b) } @b)
is far less intuitive than the proposal. I could perhaps dig into my distant
memory and explain how to accomplish something like this with PDP-8
front-panel switches, but that doesn't mean that we should not attempt a
loftier solution.
IMHO Perl should add a plethora of higher-order functions for arrays and
hashes, and from the chatter here I think a lot of people agree. Put them
there and if people don't want to use them, fine. Give us lots of ways to do
things- we know that's Perlish.
Personally, I don't like the "in" choice- I favor symbols over words, but
its better than not having it at all. Conflicts with barewords, especially
in hash refs, can be a problem. Do away that the conflict by favoring
symbols over words.
Ed
-
From: Garrett Goebel [EMAIL PROTECTED]
To: 'Jonas Liljegren' [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: RE: $a in @b
Date: Wed, 6 Sep 2000 09:43:03 -0500
From: Jonas Liljegren [mailto:[EMAIL PROTECTED]]
Does any other RFC give the equivalent to an 'in' operator?
I have a couple of times noticed that beginners in programming want to
write if( $a eq ($b or $c or $d)){...} and expects it to mean
if( $a eq $b or $a eq $c or $a eq $d ){...}.
I think it's a natural human reaction to not be repetative. An 'in'
operator will help here. It could be something like this:
$a in @b; # Has @b any element exactly the same as $a
$a == in @b; # Is any element numericaly the same as $a
$a eq in @b;
$a in @b; # Is $a bigger than any element in @b?
$a not in @b; # Yes. Make 'not' context dependent modifier for in.
grep { ref($a) eq ref($b) } @b) # Same type?
grep { $a == $_ } @b)
grep { $a eq $_ } @b)
grep { $a $_ } @b)
(grep { $a != $_ } @b) == @b)
Garrett
_
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Share information about yourself, create your own public profile at
http://profiles.msn.com.
Re: Nice to have'it
Hey Raptor et al:
Wow you did some homework! Nice ideas, but the consensus seems to be "roll
your own". I've noted that opertors working on arrays are generally
discouraged in favor of scalar ops in these discussions, so for example your
(min,max) (ceiling, floor) are coded thousands of times by hundreds of
people each year since there is no primitive. I assume, but may be
incorrect, that this is an offshoot of people never having coded in a
language resplendent in array and matrix ops, but once you have, its hard to
go backwards..
My take is that the lack of array/matrix operators reduce the productivity
of the Perl community. The language should be rich in array (and matrix)
operators so we don't waste our time coding our personal favorite ceiling
operator (yes I know its simple, that's why I don't want to waste time on
it).
As Larry said in Monterey this year (I paraphrase),
"Difficult things should become easy, and the impossible should become
difficult."
Following that logic- shouldn't easy (ceiliing) become trivial (a primitive
op)?
my 2c
From: "raptor" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Nice to have'it
Date: Mon, 28 Aug 2000 14:10:26 +0100
Hi,
I have couple of ideas which may or may not worth it, so I didn't
wrote the RFC but will list them here in short.
Here are the nice to have'it.
1. There will be good to have some sort of "match and/or assign" operator
for structures i.e. HASHES. Can't still figure out the syntax but may be
it must borrow some ideas from "switch/case" and Pascal
"with" it should be also easy to say :
if ( %a match %b )
or
%a assign_diff %b - assign and/or add all key and/or values from %b which
are
not in %a OR diff ... :")
2. "in" operator i.e.
$a in (5,6,10,33,45)
$a in @b
3. min,max,avg !!!
$a = min(5,6,10,33,45)
if ( max(@b) 22 ) ...
4. op() - Prolog like operator/keywords precedence.
f - position of the op/keyword
x - if there are more operators in this operand they must be lower
precedence
y - if there are more operators in this operand they must be
equal or lower precedence.
yfx - left-associative evaluate from left to right
xfy - righ-associative evaluate from right to left
op(100,yfx,"*");
op(200,yfx,"+");
this mean that :
a+b*3 is (a+b)*c, but not a+(b*c)
More interesting will be redifining the keywords :")
5. Persistency and easy integration in other systems as example mod_perl,
deamons like stuff etc... THE CLUE
6. CPAN = module - bundle - distribution
Distriburion(many modules+many bundles) to be something that the OS
vendors
will add to their OS's or other people do separately.
F.e..Perl Power Pack.
Primary task as small as possible interaction with the user...
many of the current CPAN modules can't install successfuly on the fly
'cause thay need some info for which they ask interactively.
In some extent this can be achieved for OS vendors 'cause they know
their Config better..
7. DBM f/locking support in standard Perl
8. The following syntax to be possible :
$hash{/re/} i.e. this is the same like
my @res;
foreach my $k (keys %hash)
{
if ($k =~ /re/) {push $hash{$k},@res}
};
OR
keys %hash{/re/}
values %hash{/re/}
each %hash{/re/}
This is very usefull for fast searching in DBM for example.
9. 64-bit aware Perl - Merced is comming !!!
10. I know this is very hard or some may argue against this, but I think
it should be possible to hack perl itself easy by every "seasoned" Perl
programmer i.e. some possibility to change language on the fly.
(And not only by the Perl-core-hackers).
A good steps toward that direction are Filter and Inline modules...
further it will be very good if we can Lex/Yacc-ing in Perl,
preprocesing source etc..
11. "Gobble" parameters from both sides i.e.
sub add(x,y){ }
may act like this :
x add y
add x,y
add(x,y)
This should be some play with Prototypes. I think also that it is good as
mantioned in one RFC that there should be the way that we can have several
subs with the same name and depending on their number of params executed is
that one that match..i.e
sub add(a,b) {}
sub add(a,b,c) {}
If I call add(4,5) the first one is executed, if I call add($c,12,45)
second one.
12. CONTEXT - there should be a way to define different and new types of
contexts. Let we think what is a context ?
Shortly it is - THE WAY WE PASS PARAMETERS and THE WAY WE RECIEVE THE
RESULT.
So the context can be SUB that accept a reference to all the params and
return
reference - may be .. i.e.
sub add(a,b) { return $a+$b };
this SUB is supposed to handle the scalars, but when we use it in
array context it shold do whatever is expected she to do w/o
explictly code this in the SUB or to be more clear DWIM.
(the description again can be handled to some extent by the prototypes)
then :
{
context array;
@c = add @a,@b; # or better @a add @b
}
sub array
{
$sub = shift;
@refs = @_;#not the same but just example, leave details for you
my
Re: RFC 76 (v1) Builtin: reduce
Making 0 the first element makes as much sense as 1- just a convention.
However there is precedence for letting the user decide. Does anyone else
remember
)ORIGIN 1
? So we establish a var $something=n where n is the array origin.
I don't think I'd ever use it personally, having been a c "kinder", but I
don't presume to thinkk like everyone else and others may be more strongly
fixated on another origin.
From: Nathan Wiger [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], Glenn Linderman [EMAIL PROTECTED]
Subject: Re: RFC 76 (v1) Builtin: reduce
Date: Sun, 27 Aug 2000 19:02:25 -0700
Damian Conway wrote:
But ^1, ^2, etc. have *nothing* to do with $1, $2, except analogically.
And I'm removing that analogy from the next version of the RFC! ;-)
They have *everything* to do with $_[0], $_[1], $_[2], etc.
I realize this, but I don't think most people will see it that way. I
see the analogy part much more clearly. Having ^1 and $1 be the same
makes a lot more sense than having $1 and ^0 both be the start.
Why? Consistency is key. With arrays, people understand that [0] is the
first element because they're dealing with a computer.
But with regexps (and HOFN), we're now into stuff that's good for
humans. And the "First" element should be "^1", just like for regexps.
Unless you want to start telling people that the "Zeroeth" element is
"^0".
But having the "First" element be "0" makes *no* sense. Not for humans.
It never has.
In fact, every kind of indexing in Perl -- *except* $1, $2, etc. --
starts at zero. Fixing $0's semantics would be far more consistent than
breaking ^0.
That's fine too - if we want to do this, let's! Honestly. I say:
1. Make $ARGV[0] have the program name
2. Make $0 be the first regexp match
But I see two problems with this:
1. Now "for (@ARGV) breaks"
2. The "first" argument is now "0" again
Please! Make the "first" be ^1. It's more consistent and makes more
sense for us humans.
We're not "breaking ^0" either - it doesn't exist yet. Rather, we're
fixing it before the bug hits the customer. I guarantee you this will be
a common mistake, I've done tons of work in real-life user-interface
testing. Users see *simple* analogies, not deep ones ("^1 like $1, the
first one")
If I ask you to count to ten, which number do you start with?
-Nate
_
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Share information about yourself, create your own public profile at
http://profiles.msn.com.
I'll try once more..
Having just coded some more perl resplendent with this syntax:
$in{pmonth}=$usr{paidon};
$in{pmonth}=~s/^.+([A-Za-z]{3,3}).+$/$1/;
once again I'll suggest (then I quit)
$in{pmonth}=~s/^.+([A-Za-z]{3,3}).+$/$1/,$in{paidon};
is a LOT nicer, and more Perlish (see split) way of doing this. I'm tired of
using two expressions for what should clearly be one.
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
Re: ... as a term
Excellent idea- anything to get to production faster!
But don't {} or {1} sort of do the same thing?
From: Larry Wall [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: ... as a term
Date: Mon, 21 Aug 2000 09:09:01 -0700 (PDT)
Randal L. Schwartz writes:
: if ($a == $b) { ... } # should this be string or number
comparison?
Actually, it's a syntax error, because of the ... there. :-)
But that reminds me of something I wanted a few months ago.
I'd entertain a proposal that ... be made a valid term that happens
to do nothing, so that you can run your examples through perl -c for
syntax checks. Or better, make it an official "stub" for rapid
prototyping, with some way of getting a warning whenever you execute
such a stub.
Larry
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
Do we really need eq?
Is eq needed? Can't == be used for either context? $a == 'cat' is readily distinguishable from $a == 2; so the compiler should be able to determine context. Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
Re: command line option: $|++
Sounds like a good idea. I propose a commandline arg that gives info about modules in @INC also. I emailed this to the list earlier but it never seemed to make it. Something like perl -M 'Digest' might return: /usr/local/lib/perl5/site_perl/: -r--r--r-- 1 root other 4733 Aug 5 1999 Digest.pm From: Uri Guttman [EMAIL PROTECTED] Reply-To: Uri Guttman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: command line option: $|++ Date: Tue, 15 Aug 2000 00:08:24 -0400 i just found an interseting little oddity i want fixed. i (like many of you) run one liners for testing snippets of code. i typically use a -p or -n loop and type in test data. i get tired of retyping in all the data each time when i want to edit the previous line only a little bit. i tried using ssfe (split screen front end, comes with sirc char client) and i saw no output due to pipe buffering. so i had to put a $|++ in the one liner to make it work. perl6 should have a command line option to enable $| for STDOUT. i haven't see any threads about perl's command line options. like the special variables, i think it could use a good editing and overhaul. 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 Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
Re: RFC 83 (v1) Make constants look like variables
I agree that constants deserve a prominent place in Perl, as they offer
constaint which can be beneficial to programmers. Sometimes its nice to know
that I mistakenly tried to treat a static variable as dynamic.
I disagree with "const" as it's verbose; I'd rather see something like
$pi=|3.14128 or something similar.
I've noted a few messages here with statements like "it looks like C++" and
"I hated that in Pascal" and so on. If we restricted ourselves to constructs
not found in other languages, there would be no Perl as we know it today.
Larry freely admits he borrowed constructs and techniques from many
languages.
There are many logical reasons for and against the RFC's here, but saying
"it looks like c so it doesn't make it for me" is a weak argument at best.
-WQ
From: Steve Simmons [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], Steve Simmons [EMAIL PROTECTED],Larry Wall
[EMAIL PROTECTED], Mike Pastore [EMAIL PROTECTED],Jeremy
Howard [EMAIL PROTECTED]
Subject: Re: RFC 83 (v1) Make constants look like variables
Date: Mon, 14 Aug 2000 12:57:14 -0400
On Sat, Aug 12, 2000 at 06:18:08AM +1000, Damian Conway wrote:
Please, please, please, PLEASE, let us not replicate the debacle that is
C++'s const modifier!
It doesn't feel like a debacle to me, it feels like it put the control
in the programmers hands. Yes, the syntax is often unweildy -- but IMHO
that's because when one marries the idea of constants to complex data
structures and references, the world becomes an unweildy place.
On the other hand, many of the uses of constants are better-satisfied
by having hidden or inaccessible members. If constants were limited
to `core' perl data types (scalars, lists, arrays and hashes) and
*completely* freezing the data element, that'd be enough for me. I lust
to be able to do things like
if ( $HOME =~ /indiana/ ) {
local $::PI : const = 3; do_trig();
} else {
local $::PI : const = 3.14159...; do_trig();
}
(I'm from Indiana and claim right to use that joke without being
insulting). Constants are good, and I'm damned tired of fixing code like
if ( $PI = 3 ) {
# We're not in Kansas any more, Toto.
}
Constants have a place, and belong in perl.
Now, one may argue that my suggestion was too flexible or too broad.
But the initial proposal left an awful lot of gray areas. If my proposal
is felt to be too unweildy, I don't have a problem with that. Let's
either
o decide where to draw the line, define it cleanly, and say
that more complex usage is better done with objects; or
o permit both complex constants and object-based manipulations
on the practice that TMTOWTDI.
I lean towards the latter (complex constants) myself, but wouldn't
go off and storm the barricades to get it. On the other hand, I
*would* campaign strongly for constant scalars, lists, arrays, hashes
and refs. If the only way to get them meant `completely constant',
ie, no addition or removal or members, no re-orderings, etc, that's
fine -- composition of complex constants with complex vars would let
one do most of what was suggested in my longer posting, and I'd be
happy to say the odder features should be done via object methods.
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
hash to hash reduction operator
I now you all will kill me for this but here goes..
this is slow:
foreach (keys %h)
{if (/some regex/) {$h2{$_}=$h{$_}}
}
In other words, extract a new hash from an existing one by searching for
primary keys matching a regex. (Please don't get off on your solutions to
this or syntax corrctions- that's not the point of this message..)
Particularly useful for tied hashes using GDBM where the key is actually a
compound key such as 'Tom Smith+Mycity+NY+13404' we could find all NY-ers
using
foreach (keys %h) {if (/\+NY\+/) {$h2{$_}=$h{$_}}
but try it on 50,000 keys.. ACK, time for a coffee break.
Now I'm not even sure what mechanism to ask for except something far more
optimal be made available in the language. A way to slice it in n-space as
opposed to n*n?
I guess what I really would need for speed is primary/secondary indices and
I suspect the gentry here will (rightfully) send me packing for my MySQL
DBI. But I thought I'd suggest this possibility since Larry said this is a
brainstorming exercise right now.
Something like secondary indices for hashes of hashes perhaps?
Ducking and covering..
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
chomp unchomp
Here is the argument- Perl has (had?) chomp(). It removes \n at the end of a line. That's something we often need to do. We ALSO often need to ADD \n to the end of a line. This usually looks something like: print "$kitty\n"; Hence my println() suggestion. Maybe instead it should be: unchomp; print; Where unchomp ADDS \n to the end of text if it isn't already there. If there is chomp there should be unchomp- the reasons for including it are the same as for including chomp. If chomp is optimized so too can unchomp. Having chomp without unchomp would be like having = but not having = [see note]. Sure you can get by without it- just change the order of the args, but why would you want to? If you have one, the other needs to be there for, if nothng else, parity. BTW I never suggested println() was in the language before. I just glommed onto another thread inadvertantly. Sorry! Ed note- in Programming Perl v2 and v3 this IS the case by the way- the = (ge) logical operator is not in the book! Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
RFC: Perl Switch for @INC searching
Short of writing a perlscript to do it, searching @INC for modules can be a pain. How's about a switch that searches @INC for modules matching a regex instead of executing anything (behaves like perl -v), so for example: perl -M 'spook' might return /usr/local/lib/perl5: -rw-r--r-- 1 root other 13889 Mar 21 1996 spook.pl or perl -M 'st\D+' /usr/local/lib/perl5: -r--r--r-- 1 root other 658 Jan 11 1996 stat.pl -r--r--r-- 1 root other 2175 Jun 4 1997 strict.pm Just a thought. -E Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
Re: Things to remove
As long as were culling, might want to consider removing chomp() and possibly chop(). The language provides other ways to accomplish those thru a simple regex, and if the "println" suggestion I made was "too specific" then certainly chomp() is as well. Just a thought to chomp on.. E Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
Re: Things to remove
I like this approach, in that it places the complexity outside of the loop.
Another generalized approach might be a new $ var which turns autochomp off
and on for all fh's (are there any $'s left? :D ).
Cheers,
Ed
From: Jonathan Scott Duff [EMAIL PROTECTED]
To: Ed Mills [EMAIL PROTECTED], "Brust, Corwin" [EMAIL PROTECTED],
[EMAIL PROTECTED], 'Simply Hao' [EMAIL PROTECTED]
Subject: Re: Things to remove
Date: Tue, 8 Aug 2000 13:21:56 -0500
On Tue, Aug 08, 2000 at 01:53:21PM -0400, Ted Ashton wrote:
I'm not sure if I'm the someone you meant, but if so, the proposal was
to make
while (chomp(FH)) { ... }
work like
while (FH) { chomp; ... }
Oh. I think I'd prefer to see chomp() go away and be replaced by
something like this:
$fh = open "foo" or die;
$fh-auto_chomp = 1;# Insert some appropriate syntax
$fh-newline = "\n";# Insert some appropriate syntax
while ($fh) {
...
}
close $fh;
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
RFC: println()
I actually saw this in the newsgroups and thought it was a neat idea. What about println $textvar; instead of print "$textvar\n"; Ever so much easier to read and write, prints the arg and appends \n. Thank-You for consideration, great ideas I'm seeing here! -Ed Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
