Damian Conway <[EMAIL PROTECTED]> writes:
> Errr. I would imagine that $ME contains:
>
> * a reference to the object, within an object method
>
> * the name of the class, within a class method
>
> * a reference to the *subroutine* itself, within a non-method.
Ooh, recursive a
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
>
> i
[EMAIL PROTECTED] wrote:
> I think all discussion fo RFC 76 (reduce) should be on the new -data
> sublist. Jeremy, am I on track here?
>
You sure are. Any stuff related to data crunching features belongs over
there, please.
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].
Even if you succeed in making access to @_ as fast as access to $a
In [EMAIL PROTECTED], you wrote:
> count = array; # scalar context because of assignment to
> scalar.
> alt_array[] = array; # list context
and if array is a subroutine?
count = array();
count = &array; # warning - special meaning in p5.
Either would be just as messy
>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 #
>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 w
Ken Fox wrote:
> Dave Storrs wrote:
> > On Thu, 17 Aug 2000, Jonathan Scott Duff wrote:
> > > BTW, if we define C 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, "
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Subroutines should be able to return an lvalue
=head1 VERSION
Maintainer: Johan Vromans <[EMAIL PROTECTED]>
Date: Aug 18, 2000
Last Modified: Aug 21, 2000
Version: 2
Mailing List: [EMAIL PROTECTED
Those rule are hard to read. I've tried reading them quite a few times
and I have trouble understanding them. I can't tell if the rules are
complex or it simply needs to be reworked. If it is complex then I
don't think this is the right approach. The rules should be simple.
As for legacy. I stron
At 11:03 AM 8/21/00 -0400, Chaim Frenkel wrote:
>Those rule are hard to read. I've tried reading them quite a few times
>and I have trouble understanding them. I can't tell if the rules are
>complex or it simply needs to be reworked. If it is complex then I
>don't think this is the right approach.
http://www.cminusminus.org/ has pointers to three implementations.
None are 'industrial strength' yet.
You can't really implement C-- on top of C efficiently, because of (a) tail
calls
and (b) the runtime interface for garbage collection, exception handling
etc. But you can do it inefficiently,
Damian Conway wrote:
> And don't forget to include my idea that $ME be scoped locally like
> $AUTOLOAD, so that the "self" and "this" and "I" and "myself" camps can
> have their respective cakes but the rest of us don't have to eat them:
Given
1: full access to the "behind-the-scenes"
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Overview: Perl OO should I be fundamentally changed.
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 21 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 137
=head
If we are going to use this, I'd like to see us standardize on the
highest-precision (i.e. attosecond) version. While it's not necessary in
any application that I can currently think of and will probably never be
necessary in 90% of Perl applications, when you need it, you need it, and
if the cor
-Original Message-
From: Tony Olekshy [mailto:[EMAIL PROTECTED]]
So, now you can say:
catch grep { $_->isa("Foo") } @@ { ... }
Ok, I think I could learn that.
"Brust, Corwin" wrote:
>
> In the context of a catch block, if could @_ contain the
> exception stack, starting with
Steven W McDougall wrote:
>
> Does Perl6 support Symmetric MultiProcessing (SMP)?
>
> This is a *huge* issue. It affects everything else that we do with
> threads.
No it isn't. SMP is completely somebody else's problem. We need
a language that worlks right on a single processor. If the hook
Dave Storrs <[EMAIL PROTECTED]> writes:
> If we are going to use this, I'd like to see us standardize on the
> highest-precision (i.e. attosecond) version. While it's not necessary
> in any application that I can currently think of and will probably never
> be necessary in 90% of Perl applicatio
Perl6 RFC Librarian wrote:
>
> As a thought guide: think of C returning a reference to its
> argument, and the call to lvsub() performing a dereference.
Thought guide? Given a macro language and reference reasonablizing,
this looks like you've just compeltely defined lreturn!
macrod
>From rfc 98:
> =head2 acceptable coercions
>
> When resolving which method C to call in a context CTXT, and there
> is no method C defined for the context CTXT, Perl will examine
> the types listed in C<@CTXT::ISA{OVERLOAD_CONTEXTS}> for a list
> of other contexts
> to see if C can produc
> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
PRL> A C keyword that lexically scopes hash keys to the current
PRL> package, and allows hashes to contain two or more identically named (but
PRL> differently scoped) entries. This would solve the problem of
PRL> encapsulation
Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
> You can't really implement C-- on top of C efficiently, because of
> (a) tail calls and (b) the runtime interface for garbage collection,
> exception handling etc.
Agreed. But any practical C-- implementation will start with a C/C++
compiler so tha
Jeremy Howard writes:
: How much hand-waving can we do with implementation efficiency of anonymous
: subs and higher order functions? How much can we expect Perl to optimise
: away at compile time? For instance, if:
:
: $sum = reduce ^_+^_, @list;
:
: has any substantial overhead on each itera
Today around 3:34pm, Tom Christiansen hammered out this masterpiece:
: >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...
: >:
>: 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?
> 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 C 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 sort of
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
[EMAIL PROTECTED] writes:
: I take it the existing C<...> operator would be unaffected?
Essentially. The lexer is (and will continue to be) quite aware of the
difference between terms and operators.
The interesting thing about ... is that you have to be able to
deal with it a statement with an
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() exp
> : In a void context, C 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, 2,
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 c
> [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
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
>
[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
> In a void context, C dumps the program's current opcode representation
> to its filehandle argument (or STDOUT, by default).
>
> In a scalar or list context, C dumps nothing, but rather returns the
> I of its arguments (or of the current state of the entire
> program, by default).
Instant prog
> Instant program migration:
>
> host-a:foo.pl: print SOCKET dump;
>
> host-b:bar.pl: { local $/; eval };
If domeone is putting this RFC together, please remember to propose
that C and C should handle opcodes as well as source:
host-a:foo.pl: dump SOCKET;
Damian Conway writes:
> If domeone is putting this RFC together, please remember to propose
> that C and C should handle opcodes as well as source:
>
> host-a:foo.pl: dump SOCKET;
>
> host-b:bar.pl: { local $/; eval };
>
> Or:
>
> sub suspend { open $fh, ">$_[0]" or die; d
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 <
-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
Ed Mills writes:
: But don't {} or {1} sort of do the same thing?
Well, { warn "Encountered stub"; (); } would be more like it. But the
biggest problem with {} or {1} is that they don't resemble an ellipsis.
Larry
> 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
"Bryan C. Warnock" wrote:
>
> On Fri, 18 Aug 2000, David L. Nicol wrote:
> > There will Be No Perl7
>
> Of course not. Odd numbers are the development releases. The next
> Perl after 6 will be 8.
So maybe the reference implementation should be written in perl 4. Did
perl 4 have references?
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 ag
Why is it that in perl 5 I can do:
use English::Dereference; #Or equivalent, relevant section included below
sub ARRAY {
return @{ shift() };
}
sub HASH {
return %{ shift() };
}
print join(' ', ARRAY [1,2,3,4]), "\n";
And the seemingly parallel:
print join(' ', HASH {1,2,3,4}), "\n";
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
(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 mentio
>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 LIST, not a HASH nor an ARRAY. Likewise, it can only
receive a LIST, not those o
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 DIC
> "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
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) { ... }
>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 cal
>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 isn
> 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?
I
> : 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 Right Thing.
> (I suspect it shou
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
> > > 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
> > 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
On Mon, Aug 21, 2000 at 05:49:39PM -0700, Larry Wall wrote:
> [EMAIL PROTECTED] writes:
> : I take it the existing C<...> operator would be unaffected?
>
> Essentially. The lexer is (and will continue to be) quite aware of the
> difference between terms and operators.
Oops, just read this. Ign
[EMAIL PROTECTED] writes:
: How about this then:
:
: In a void context, C 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 inter
> "TO" == Tony Olekshy <[EMAIL PROTECTED]> writes:
TO> 2. Multiple conditional catch clauses now work like a switch,
TO> instead of like a bunch of sequential ifs.
TO> This always bugged me too, but I couldn't nail it down
TO> until the debate about using else/switch instead of
On 22 Aug 2000, Chaim Frenkel wrote:
> Could you tell me why you would want two finallys?
>
> Why not put them into one?
> TO> my ($p, $q);
> TO> try { $p = P->new; $q = Q->new; ... }
> TO> finally { $p and $p->Done; }
> TO> finally { $q and $q->Done; }
Presumably because all f
> "TO" == Tony Olekshy <[EMAIL PROTECTED]> writes:
>> As for legacy. I strongly urge that Modules _never_ die.
>> It is extremely rude.
TO> The contract between a module and its client is beyond the scope
TO> of RFC 88. However, I take it from your strong stance that you
TO> wrap every ++$i
Executive Summary:
We should go to a pure return-based mechanism for error signalling,
or a pure exception-based one. We can't do the former. Therefore
we should do the latter.
Author's Note:
I'm a pragmatist. I'll keep using return-based error signalling
for some purposes, just li
> "TO" == Tony Olekshy <[EMAIL PROTECTED]> writes:
TO> Perl's behaviour after a C starts call-stack unwinding, as
TO> envisioned by this RFC, is as described by the following rules.
TO> 1. Whenever an exception is raised Perl looks for an enclosing
TO> try/catch/finally clause.
TO>
Could you tell me why you would want two finallys?
Why not put them into one?
> "TO" == Tony Olekshy <[EMAIL PROTECTED]> writes:
TO> Non-shared:
TO> my ($p, $q);
TO> try { $p = P->new; $q = Q->new; ... }
TO> finally { $p and $p->Done; }
TO> finally { $q and $q->Done; }
TO
> "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
PS> However, my memory as to what the current perl behavior is was faulty;
PS> continue blocks do *not* share the lexical scope of their attached loop
PS> blocks. I was misremembering the caveat at the end of this part of perlsyn
PS> (whic
Hello
This is a follow up to various discussions about localtime() and time
objects on the other lists. I hope this is not out of scope as all this
could be done already with Perl 5 and a module (though I think it really
belongs into the distribution)
In my opinion there's no reason for localt
Markus Peter writes:
> > use %record{
> >
> > $\interest_earned += $\balance * $\rate_daily;
> > };
Guys, where in the sweet name of Jesus did this awful syntax
come from?
For a start,
%start{ }
is only analogous to a slice operation. It has no precedent in
Perl.
Normally what
Uri wrote:
> PRL> A C keyword that lexically scopes hash keys to the
> PRL> current package, and allows hashes to contain two or more
> PRL> identically named (but differently scoped) entries. This
> PRL> would solve the problem of encapsulation in OO Perl for the
> PRL>
--On 18.08.2000 14:36 Uhr -0700 David L. Nicol wrote:
> How about backslash, after the type-qualifier?
>
> use %record{
>
> $\interest_earned += $\balance * $\rate_daily;
> };
I don't really like having backslashes in front of ordinary characters
anywhere except when I mean them :-) (\n,
-Original Message-
From: Damian Conway [mailto:[EMAIL PROTECTED]]
And don't forget to include my idea that $ME be scoped locally like
$AUTOLOAD, so that the "self" and "this" and "I" and "myself" camps can
have their respective cakes but the rest of us don't have to eat them:
[...]
> 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.
I was cont
> 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 developm
Larry Wall wrote:
>
> Ed Mills writes:
> : But don't {} or {1} sort of do the same thing?
>
> Well, { warn "Encountered stub"; (); } would be more like it. But the
> biggest problem with {} or {1} is that they don't resemble an ellipsis.
>
> Larry
dot operator selection:
The token clarifie
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
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 whenever you execute
>
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
> 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 warni
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, intuit
> : And whilst you're in a mood to ignore whitespace, how about C<$/ = "">
> : terminating on C?
>
> I'm more inclined to ignore $/ these days. :-)
Well, just give me a regex getline terminator or pattern matches against
filehandles (a la RFC 93) and I'll never mention $/ again ;-)
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 { "@_" }
>}
Probably have to punt on checking user code in a main routine that does
Damian Conway <[EMAIL PROTECTED]> writes:
>> : And whilst you're in a mood to ignore whitespace, how about C<$/ = "">
>> : terminating on C?
>>
>> I'm more inclined to ignore $/ these days. :-)
>
> Well, just give me a regex getline terminator or pattern matches against
> fileh
> 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?/
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
>No. ke
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:
> 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.
92 matches
Mail list logo
