Here in my pre-caffiene morning trance it occurs to me that a few of
the "fringe" features of perl should be removed from the langauge.
Here's a few things that I would venture to say that none of the
"perl5 is my first perl" people have probably ever actually used.
reset # How
I've very rarely found cases where ?? was useful and // didn't work, and
never in regular code.
From the Camel:
The C?? operator is most useful when an ordinary pattern match
would find the last rather than the first occurrence:
open DICT, "/usr/dict/words" or die "Can't open
Ken Fox wrote:
Dave Storrs wrote:
On Thu, 17 Aug 2000, Jonathan Scott Duff wrote:
BTW, if we define Cwith to map keys of a hash to named place holders
in a curried expression, this might be a good thing:
with %person {
print "Howdy, ", ^firstname, " ", ^lastname;
Bart Lateur wrote:
On Thu, 17 Aug 2000 07:44:03 +1000, Jeremy Howard wrote:
$a and $b were done for speed: quicker to set up those global
variables than to pass values through the stack.
The solution is to pass args in as $_[0] and $_[1].
sort { $_[0] = $_[1] } @list
is very ugly.
I
Tom Christiansen writes:
: I've very rarely found cases where ?? was useful and // didn't work, and
: never in regular code.
:
: From the Camel:
:
: The C?? operator is most useful when an ordinary pattern match
: would find the last rather than the first occurrence:
:
: open
"Larry" == Larry Wall [EMAIL PROTECTED] writes:
Larry Randal L. Schwartz writes:
Larry : if ($a == $b) { ... } # should this be string or number comparison?
Larry Actually, it's a syntax error, because of the ... there. :-)
Larry But that reminds me of something I wanted a few months
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) { ... } #
Ariel Scolnicov writes:
: I was asked to debug a weird Perl5 problem yesterday. The code in
: question looked roughly like this (indented 4 spaces, but otherwise
: unchanged):
:
: #!perl -w
: use strict;
:
: print END;
: The next line contains a space at the end.
: END
-Original Message-
From: Ed Mills [mailto:[EMAIL PROTECTED]]
Excellent idea- anything to get to production faster!
But don't {} or {1} sort of do the same thing?
I think the point here is readability, not unique functionality.
There more then one way to do it :)
-Corwin
(thread intentionally broken)
Nathan Torkington wrote:
Steve Fink writes:
True. Would anyone mourn @$scalar_containing_variable_name if it died?
I've never used it, and I'm rather glad I haven't. Perl5's -w doesn't
notice $x="var"; print @$x either -- it'll complain if you mention @var
Still,
sort { $_[0] = $_[1] } @list
is very ugly.
Hence:
sort ^a = ^b, @list;
Damian
On Mon, 21 Aug 2000 06:11:02 -0600, Tom Christiansen wrote:
$first = $1 if ?(^neur.*)?;
$first ||= $1 if /(^neur.*)/;
Now if only we had a shortcut operator which would continue only if the
LHS was not defined...
--
Bart.
I've always wished it was the famous "do what I mean" operator:
if ($a eq "input") {
... # let perl figure out what to do here
} else {
print "I need more input!\n";
}
That'd make "rapid application development"
From: Damian Conway [mailto:[EMAIL PROTECTED]]
One could make dump "work" by having it dump out not a core or
a.out, but rather the byte codes representing the current state of
the perl machine. This seems anywhere from somewhat to seriously
useful, and follows in the spirit of what
Steve Fink writes:
My code for doing what I thought Exporter did is:
sub import {
my $p = caller(1);
*{"${p}::E"} = \%{"${p}::E"};
}
but that doesn't run afoul of use strict 'refs'. Can you point me to the
passage in Exporter.pm that uses this?
It does run afoul of use strict
One could make dump "work" by having it dump out not a core or
a.out, but rather the byte codes representing the current state of
the perl machine. This seems anywhere from somewhat to seriously
useful, and follows in the spirit of what dump was always meant to do.
[EMAIL PROTECTED] writes:
: : I would like to see a compiler warning for this:
: : "Spaces detected after apparent here document terminator", but
: : preferably phrased better.
: :
: : Are there any objections?
:
: I object, vaguely. I think it should just Do The
Instant program migration:
host-a:foo.pl: print SOCKET dump;
host-b:bar.pl: { local $/; eval SOCKET };
If domeone is putting this RFC together, please remember to propose
that Ceval and Cdo should handle opcodes as well as source:
host-a:foo.pl: dump
Damian Conway writes:
If domeone is putting this RFC together, please remember to propose
that Ceval and Cdo should handle opcodes as well as source:
host-a:foo.pl: dump SOCKET;
host-b:bar.pl: { local $/; eval SOCKET };
Or:
sub suspend { open $fh, "$_[0]" or die;
Today around 11:48am, Tom Christiansen hammered out this masterpiece:
: So basically, it would be nice if each, keys, values, etc. could all deal
: with being handed a hash from a code block or subroutine...
:
: In the current Perl World, a function can only return as output to
: its caller a
It would be nice if a human readable dump were possible. So please don't
completely dump the idea of Data::Dumper functionality in the core.
These are different things. And the bytecodes can always be B::Deparse'd, or
whatever we come up with for uncompilation.
Not that proper marshalling
dump FILE; # dump program state as opcodes
You don't like that that should be a checkpoint resurrection at the
point in the programmer labelled with "FILE:", per the current
(semi-dis-)functionality?
Hmm, what about CHECK blocks?
--tom
title: study a list of regexes
David Nicol.
Aug 21
version 1
[EMAIL PROTECTED]
Sometimes I have a group of regexen, and I would like to know
which ones will match.
Current practice is to "study" $situation and then grep them:
example a:
study $situation;
@matches = @rules{
On Mon, Aug 21, 2000 at 03:43:44PM -0600, Tom Christiansen wrote:
dump FILE; # dump program state as opcodes
You don't like that that should be a checkpoint resurrection at the
point in the programmer labelled with "FILE:", per the current
(semi-dis-)functionality?
Isn't
Ken Fox wrote:
IMHO, curries have nothing to do with this. All "with" really does is
create a dynamic scope from the contents of the hash and evaluate its
block in that scope.
Right, the "with" people are using ^hats because its an available
operator, just the same way the "curry" people
Larry Wall writes:
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
Thanks! Ok, from a type inferencing perspective...
Nathan Torkington wrote:
Symbolic references are used for dynamic function generation:
foreach my $func (qw(red green blue)) {
*$func = sub { "FONT COLOR=$func@_/FONT" }
}
Probably have to punt on checking user code in a main
In reply to your message from the not too distant future: next Monday AD
Reply-to: [EMAIL PROTECTED]
Return-receipt-to: [EMAIL PROTECTED]
Organization: a) Discordia b) none c) what's that?
Content-Typo: gibberish, charset=ascii-art
Date: Mon, 21 Aug 2000 19:04:27 EDT
From: Jerrad Pierce belg4mit
Some have been frustrated at the fact that after
@ott = (1,2,3);
$x = @ott
$x == 3.
What if one of the things that lazy arrays did differently from
normal arrays was shifting on assignment, instead of counting
themselves?
This would solve several problems at once, including:
On Mon, Aug 21, 2000 at 09:09:01AM -0700, Larry Wall wrote:
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.
: No. keys() expects something that starts with a %, not
: something that starts with a .
Wow. Now that, that, is lame. You're saying that keys() expects it's first
argument to begin with a %? Why should it care what it's argumen begins with?
You're just now figuring this out? Really?
All
The interesting thing about ... is that you have to be able to
deal with it a statement with an implied semicolon:
print "foo";
...
print "bar";
We already have plenty of statements with implied semicolons:
print "foo";
for @list {}
David L. Nicol writes:
: What if there were a faster way to do this, a way to Cstudy a
: group of regexes and have the computer determine which ones had
: parts in common, so that if $situation =~ m/^foo/ is true, the
: fifty rules that start ^bar don't waste any time. At all.
Perl 4 did this
Casey R. Tweten writes:
Wow. Now that, that, is lame. You're saying that keys() expects
it's first argument to begin with a %? Why should it care what it's
argumen begins with?
The keys function changes its arguments' data structure. keys resets
the each iterator (see the documentation
On Mon, Aug 21, 2000 at 09:00:26PM -0400, Casey R. Tweten wrote:
Today around 3:34pm, Tom Christiansen hammered out this masterpiece:
: No. keys() expects something that starts with a %, not
: something that starts with a .
Wow. Now that, that, is lame. You're saying that keys() expects
: In a void context, Cdump dumps the program's current opcode
: representation to its filehandle argument (or STDOUT, by
: default).
It's not clear to me that reusing a lame keyword for this is the
highest design goal. Let's come up with a real interface, and then if
[EMAIL PROTECTED] writes:
: We already have plenty of statements with implied semicolons:
:
: print "foo";
: for @list {}
: print "bar";
Yes, we do, and I'm trying to figure out how to write a prototype for
one of those. :-) / 2
: I'd have expected:
:
: print (1,
Today around 7:11pm, Tom Christiansen hammered out this masterpiece:
: : No. keys() expects something that starts with a %, not
: : something that starts with a .
:
: Wow. Now that, that, is lame. You're saying that keys() expects it's first
: argument to begin with a %? Why should it care
[EMAIL PROTECTED] writes:
: We already have plenty of statements with implied semicolons:
:
: print "foo";
: for @list {}
: print "bar";
Yes, we do, and I'm trying to figure out how to write a prototype for
one of those. :-) / 2
Under RFC 128 and the
On Mon, Aug 21, 2000 at 01:01:20PM -0600, Nathan Torkington wrote:
Larry Wall writes:
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
dump FILE; # dump program state as opcodes
You don't like that that should be a checkpoint resurrection at the
point in the programmer labelled with "FILE:", per the current
(semi-dis-)functionality?
Not much :-)
Maybe:
dump "FILE:"
but not just a
I'd like to see a new builtin named "in" which does the same as "in" in SQL.
Basically,
print "OK!" if $val in ("foo","bar","bla");
is the same as
print "OK!" if grep { $_ eq $val } ("foo","bar","bla");
or
print "OK!" if $val eq "foo" or $val eq
except it's a lot more compact,
I'd like to see a new builtin named "in" which does the same as
"in" in SQL. Basically,
print "OK!" if $val in ("foo","bar","bla");
Wait for the superpositions RFC:
print "OK!" if $val eq any("foo","bar","bla");
print "OK!" if $val =~ any(qr/fo+/,qr/bl?ar?/);
subscribe by sending mail to [EMAIL PROTECTED]
more details at http://dev.perl.org/lists
LIST: [EMAIL PROTECTED]
CHAIR: Mark-Jason Dominus [EMAIL PROTECTED]
MISSION:Draft and discuss RFCs related to regexp language
issues in Perl 6. Report weekly to
44 matches
Mail list logo
