"David L. Nicol" <[EMAIL PROTECTED]> writes:
> John Porter wrote:
> >
> > we should also support recursive data structures,
> > as in some functional languages. E.g. (pseudocode):
> >
> > define foo as {
> > short a;
> > foo b; # exists at first only
At 07:39 PM 8/29/00 -0700, Dirk Myers wrote:
>Tonight, the role of "Peter Scott" will be read by Perl RFC Librarian :
>
> > =head1 DESCRIPTION
> >
> > In a scalar context, the result should remain the same as it is now. It is
> > very tempting to make the list context return be the I
> > altered
Peter Scott wrote:
>
> Some people have already suggested renaming them; RFC 30
> takes the obvious step of making $STDIN, $STDOUT, $STDERR but sidesteps the
> issue of $ARGV which already has a meaning :-( If we can solve that one
> then I'd just make all those filehandles scalars.
I've been t
> On Tue, Aug 29, 2000 at 07:27:15PM -0700, Peter Scott wrote:
> > > $r->{{qw(a b c d e f g h)}}
> > > $r->{a}->{b}->{c}->{d}->{e}->{f}->{g}->{h}
> >
> > $r->{a}{b}{c}{d}{e}{f}{g}{h}
> >
> > which is only one character longer than the proposal...
>
> Except in the case wh
On Tue, Aug 29, 2000 at 07:27:15PM -0700, Peter Scott wrote:
> > $r->{{qw(a b c d e f g h)}}
> > $r->{a}->{b}->{c}->{d}->{e}->{f}->{g}->{h}
>
> $r->{a}{b}{c}{d}{e}{f}{g}{h}
>
> which is only one character longer than the proposal...
Except in the case where you don't have
>Simpify syntax of C by deleting C before the
>block and C<;> after it.
You can't do that. They do different things.
$n = do {
my $sum = 0;
for $i (@array) { $sum += $i }
$sum;
};
versus
$rec = {
FOO => 1.4,
BAR => "red",
};
--tom
>Having the
>indices in one place saves a lot of characters. Compare
>
> $r->{{qw(a b c d e f g h)}}
>
>versus
>
> $r->{a}->{b}->{c}->{d}->{e}->{f}->{g}->{h}
But I would compare it to
$r->{a}{b}{c}{d}{e}{f}{g}{h}
which is only one character longer than the proposal...
-
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Simplify C Syntax
=head1 VERSION
Maintainer: Mark Senn <[EMAIL PROTECTED]>
Date: 26 Aug 2000
Last-Modified: 29 Aug 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number: 167
Status: Developin
(aka Multidimensional Arrays/Hashes)
Reply-To: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
A Natural Syntax Extension For Chained References
(aka Multidimensional Arrays/Hashes)
=head1 VERSION
Maintainer: Jarkko Hietaniemi <[EMAI
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
subroutine / generic entity documentation
=head1 VERSION
Maintainer: Michael Maraist <[EMAIL PROTECTED]>
Date: 29 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 176
Status: De
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Add C keyword to force list context (like C)
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 29 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 175
Status: De
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Allow multiple loop variables in foreach statements
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 29 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number:
Tom Christiansen wrote:
>
> That's hardly the problem with indirect object syntax. Besides
> what I just mentioned, there is the fact that it's acting in a
> fashion that you could call stronger than a unary operator in terms
> of precedence.
This is also mentioned in the RFC, although probably
> >I intend to extend the parameter lists RFC to cover optional
> >(non-trailing) arguments.
>
> Will this include having typed variadic functions, allowing you, for
> example, to say something like
>
> This function takes any number of arrays, all passed by reference.
>Basically, it "fixes" the indirect notation by making all of these Do
>The Right Thing:
> $r = new CGI (@args); # CGI->new(@args)
> $r = new(CGI, @args); # CGI->new(@args)
> $r = new(CGI @args); # CGI->new(@args)
>It's all in the details (I'm sure you see the edge cases already, but
>
Damian Conway wrote:
>
> I intend to extend the parameter lists RFC to cover optional
> (non-tailing) arguments. Personally, I would like to see the
> indirect object syntax removed in all contexts, inclusing
> this one, and filehandles simply passed as a first argument.
Whoa there! :-)
Not nec
>For the first part, tchrist posted a nice list of non-overridable
>builtins; running my eye down it, it looks like the gross offenders
>here are:
> glob, print, printf
>I don't know whether this is purely an implementation issue (and so
>lies solely in the domain of perl6-internals) or wh
>I intend to extend the parameter lists RFC to cover optional
>(non-tailing) arguments.
Will this include having typed variadic functions, allowing you, for
example, to say something like
This function takes any number of arrays, all passed by reference.
I keep thinking of a * or a ... to
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Allow exception-based error-reporting.
=head1 VERSION
Maintainer: Bennett Todd <[EMAIL PROTECTED]>
Date: 8 Aug 2000
Last Modified: 29 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 3
Number:
>How about ALLOWING bareword everything-else? Start having
>filehandles work the way everyone expects them to at first,
>passing as arguments and so forth, without any special treatment?
One could do that, too. Or allow scoped declarations of
unadorned identifiers: this might be the road out o
I intend to extend the parameter lists RFC to cover optional
(non-tailing) arguments. Personally, I would like to see the
indirect object syntax removed in all contexts, inclusing
this one, and filehandles simply passed as a first argument.
Damian
How about ALLOWING bareword everything-else? Start having
filehandles work the way everyone expects them to at first,
passing as arguments and so forth, without any special treatment?
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Subroutine one-arg, him c
On Tue, 29 Aug 2000 19:06:24 -0600, Tom Christiansen wrote:
>>I feel that this ought to have worked, i.e. that the scope of the
>>lexical kicked in in the middle of the expression, at the transition
>>over the shortcut operator "&&".
>
>Except that then you can't say
>
>local $x = $x;
>or
>
>
> I am lazy. I am spoiled by the implicit $_. I like the implicit
> $_. Implicit $_ good. Ugh. (Conversely, some people abhor the
I believe you mean "Ug." "Ug" means you are speaking pidgin, while
"Ugh" indicates disgust.
> =head1 IMPLEMENTATION
>
> The front-end would have to detect v
One function that takes an optional leading commaless arg:
sub print(handle? $FH, @)
or
Two functions differentiated by their prototypes
sub print(@);
sub print(handle,@);
I'm always forgetting the comma after the handlename in
C statements because I learned "no c
>>sub getfh {
>> return open(my $fh, "+< /dev/null") && $fh;
>>}
>Aha! You fell for one of my pet pieves. You tried to return a lexical in
>the same expression were it was declared. That doesn't work. It's not
>the same variable. Running it with warnings enabled says:
Grr..
> Na
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Request For New Pragma: Shell
=head1 VERSION
Maintainer: Bryan C. Warnock <[EMAIL PROTECTED]>
Date: 5 Aug 2000
Last Modified: 28 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
N
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Request For New Pragma: Implicit
=head1 VERSION
Maintainer: Bryan C. Warnock <[EMAIL PROTECTED]>
Date: 5 Aug 2000
Last Modified: 28 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 3
Richard Proctor wrote:
>
> This leads back to my original "remove all whitespace". Somehow there is a
> compromise to extracted from this.
Have we explored using a subset of regex for end-markers?
$long_string_possibly_indented_later = <<\w*##ENDEND##\w*;
.
On Tue, 29 Aug 2000 18:17:46 -0600, Tom Christiansen wrote:
>You could pass it as
>
>p(*FH);
>
>instead, and the function's definition doesn't change.
Typeglobs are on the endangered species list. That is part of the reason
for this RFC.
>sub getfh {
> return open(my $fh, "+< /de
At 06:17 PM 8/29/00 -0600, Tom Christiansen wrote:
> >Eliminate bareword filehandles.
>
>"Eliminate" is such a strong word. You're saying that we can't
>use STDIN, STDOUT, STDERR, ARGV, or DATA anymore?
There are some people I would like to stop using output filehandles, yes :-)
> Heck, some
>Tom Christiansen wrote:
>>
>> >Eliminate bareword filehandles.
>>
>> "Eliminate" is such a strong word. You're saying that we can't
>> use STDIN, STDOUT, STDERR, ARGV, or DATA anymore? Heck, some people
>> still use stdin and stdout! :-)
>Disclaimer: I am not attempting to put words in anyone
Tom Christiansen wrote:
>
> >Eliminate bareword filehandles.
>
> "Eliminate" is such a strong word. You're saying that we can't
> use STDIN, STDOUT, STDERR, ARGV, or DATA anymore? Heck, some people
> still use stdin and stdout! :-)
Disclaimer: I am not attempting to put words in anyone's mouth
>This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>=head1 TITLE
>Eliminate bareword filehandles.
"Eliminate" is such a strong word. You're saying that we can't
use STDIN, STDOUT, STDERR, ARGV, or DATA anymore? Heck, some people
still use stdin and stdout! :-)
>=hea
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Eliminate the optional C for C etc block declarations
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 8 Aug 2000
Last Modified: 29 Aug 2000
Mailing List: [EMAIL PROT
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Deep Copying, aka, cloning around.
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 8 Aug 2000
Last-Modified: 29 Aug 2000
Mailing List: [EMAIL PROTECTED]
Versio
>>> > * Using an array of "words" as an alternate list as part of a regex
>>> /match any of (${\join'|',@list}) here/
>NT> $" = "|"; /@list/ # snicker
Certainly I've written
if (do { local $" = "|"; $var =~ /@any/}) { blah() }
before.
--tom
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
List context return from filesystem functions
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 6 Aug 2000
Last Modified: 29 Aug 2000
Mailing List: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
C<||> and C<&&> should propagate result context to both sides
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 5 Aug 2000
Last-Modified: 29 Aug 2000
Mailing List:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Eliminate bareword filehandles.
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 4 Aug 2000
Last Modified: 29 Aug 2000
Version: 2
Mailing List: [EMAIL PROTECTED
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
LW> : This can be very hard to discover. I find it hard to see myself doing
LW> : this on purpose. I would like to see a compiler warning for this:
LW> : "Spaces detected after apparent here document terminator", but
LW> : preferably phrased b
> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
>> > * Using an array of "words" as an alternate list as part of a regex
>> /match any of (${\join'|',@list}) here/
NT> $" = "|"; /@list/ # snicker
Is $" one of the specials scheduled for the axe?
--
Chaim Frenkel
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Built-in functions should be functions
=head1 VERSION
Maintainer: Johan Vromans <[EMAIL PROTECTED]>
Date: 27 Aug 2000
Last Modified: 28 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
Number
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> It was simply attempting to explain why I choose to ignore what are (to
DC> me, at least) trivial implementation issues, well documented in the
DC> compiler literature. I choose to ignore them because I *have* to ignore
DC> them or my br
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Named operators versus functions
=head1 VERSION
Maintainer: Johan Vromans <[EMAIL PROTECTED]>
Date: 04 Aug 2000
Last Modified: 28 Aug 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number: 26
John Porter wrote:
>
> we should also support recursive data structures,
> as in some functional languages. E.g. (pseudocode):
>
> define foo as {
> short a;
> foo b; # exists at first only "in potential".
> long c;
> };
>
h
> I was thinking that the switch statement could possibly be expanded
> to also behave as an operator and not just a control statement.
I had considered this, but didn't put this in because no other
Perl control statements return a value. Personally, I like the
notion a great deal.
What th
>went through the archives about RFC22 "builtin switch statement".
>didn't see any mention of this, thought I'd throw it in there to see
>how it was recieved.
>I was thinking that the switch statement could possibly be expanded
>to also behave as an operator and not just a control statement.
>i.
the semicolon after the hereis terminator thing might
only work if the beginning of the hereis was the last thing
on the line it appears on, that way there's no ambiguity
$Goodone = <
> I like it... I think I will add this to the next version.
>
> Richard
>
> --
>
> [EMAIL PROTECTE
went through the archives about RFC22 "builtin switch statement".
didn't see any mention of this, thought I'd throw it in there to see
how it was recieved.
I was thinking that the switch statement could possibly be expanded
to also behave as an operator and not just a control statement.
i.e. the
>Tom Christiansen wrote:
>> >Well, as I mentioned in another recent parallel thread, if C is to
>> >be properly functionalized,
>>
>> Whoa -- why? Syntax keywords (eg if, unless) certainly need not be
>> expressible as functions.This isn't tcl!
>Ah, the old "If you want Tcl, you know where
Eric Roode wrote:
> >
> >Also the ability to traverse multiple lists at once
> >
> > for ($a,$b,$c) (zip(@a,@b,@c)) { ... }
>
> I don't get it. This is a great advantage over:
>@looparray = zip(@a,@b,@c);
>while ( ($a,$b,$c) = splice (@looparray, 0, 3))
> ?
>
Because splice() is destructi
> > You know, I would like to pass code blocks in any arg position;
> > I want sub foo(&\@&\@&) to be callable as
> >
> > foo { alpha() } @bravo { charlie() } @delta { echo() };
> >
> > No Cs, no commas.
Already in the RFC.
> And one further note: it would be nice if,
> today this just came up to my mind, we could have a pragma that
> disable `autovivification' of hash and array keys. Consider the
> follow code snippet:
>
> @arr = ( 0..9 );
> %hash = ( a=>1, b=>2 );
>
> {
> no autovivify;
> $arr{10}++; # both are
"David L. Nicol" wrote:
> 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.
...
> But that doesn't give us the speed win we want from compiling offset lookups
>
Lightning flashed, thunder crashed and Michael G Schwern <[EMAIL PROTECTED]> wh
ispered:
| On Thu, Aug 24, 2000 at 08:29:21PM -, Perl6 RFC Librarian wrote:
| > The C and C commands are legacy commands which have been
| > deprecated for at least 5 years. They should be removed from the languag
At 03:46 PM 8/29/00 -0400, Eric Roode wrote:
>Okay, brainstorming here ... bear with me.
>
>What if limit-of-error precision were tracked, as Perl tracks tainted
>variables when you tell it to?
Can't be done that way, unfortunately. You need to enforce significant
digits at every step of the cal
John Porter wrote:
>
> You know, I would like to pass code blocks in any arg position;
> I want sub foo(&\@&\@&) to be callable as
>
> foo { alpha() } @bravo { charlie() } @delta { echo() };
>
> No Cs, no commas.
And one further note: it would be nice if, given a prototype
which does
Dan Sugalski wrote:
>At 02:49 PM 8/29/00 -0400, Andy Dougherty wrote:
>>On Tue, 29 Aug 2000, David L. Nicol wrote:
>>
>> > I'd like to see every number bundled with a "precision" attribute.
>>
>>While that might be useful for simple calculations, I expect it would
>>simply get in the way and slow
It's probably worth reading through the Python Enhancement Proposals
(PEPs) to see if there's anything that makes sense to steal:
http://python.sourceforge.net/peps/
Nat
Graham Barr wrote:
> Also it hash been
> suggested that it could potentially replace each
>
> for my($k,$v) (%hash) { ... }
Continuing my crusade for beefier prototypes, I can easily envision this:
for(\$\$\%&);
callable as
for ($k,$v) %h { }
--
John Porter
We're
Tom Christiansen wrote:
> >Well, as I mentioned in another recent parallel thread, if C is to
> >be properly functionalized,
>
> Whoa -- why? Syntax keywords (eg if, unless) certainly need not be
> expressible as functions.This isn't tcl!
Ah, the old "If you want Tcl, you know where to fin
At 02:49 PM 8/29/00 -0400, Andy Dougherty wrote:
>On Tue, 29 Aug 2000, David L. Nicol wrote:
>
> > I'd like to see every number bundled with a "precision" attribute.
>
>While that might be useful for simple calculations, I expect it would
>simply get in the way and slow things down for larger, mor
At 03:24 PM 8/29/00 -0400, John Porter wrote:
>Peter Scott wrote:
> >
> > Yes, please. I view the flattening of lists as a feature, not a bug, and
> > it has made Perl a lot easier to understand IMHO.
>
>So... is an RFC forthcoming? Or shall I?
I mailed an RFC on multiple loop variables in for(
Andy Dougherty wrote:
>
> On Tue, 29 Aug 2000, David L. Nicol wrote:
>
> > I'd like to see every number bundled with a "precision" attribute.
>
> While that might be useful for simple calculations, I expect it would
> simply get in the way and slow things down for larger, more complex
> calcula
Peter Scott wrote:
>
> Yes, please. I view the flattening of lists as a feature, not a bug, and
> it has made Perl a lot easier to understand IMHO.
So... is an RFC forthcoming? Or shall I?
--
John Porter
We're building the house of the future together.
Chaim Frenkel wrote:
>
> We should be able to represent
> any packed structure. We should be able to handle anything that an
> pack/unpack format can currently handle.
> ...
> The raw structures could be passed between perl and the XS unchanged.
>
> the COBOL redefines capabilities.
> ...a met
At 02:57 PM 8/29/00 -0400, John Porter wrote:
>But as for the semantics... how does perl handle this:
>
> for ($x,$y,$z) (@a1,@a2) { ... }
>and
> for ($x,$y,$z) (@a1,@a2,@a3,@a4) { ... }
>
>Making the case where the number of iterators == the number of arrays
>special may not be so
Jonathan Scott Duff wrote:
> I'm wondering how we get both
>
> for ($x,$y,$z) (@array) { ... }
>
> and
>
> for ($x,$y,$z) (@array1,@array2,@array3) { ... }
That's an -internals issue. Suffice it (here) to say that
the parser could be made to handle it. In fact, to the parser,
it'
Al-
> In some of the OO stuff people (me included) wanted to see simple scalars be
> able to act "like" objects.
You'll be particularly interested in RFC's 159 and 161, and discussions
on -objects. Check out these emails in particular:
http://www.mail-archive.com/perl6-language-objects%40perl.
On Tue, 29 Aug 2000, David L. Nicol wrote:
> I'd like to see every number bundled with a "precision" attribute.
While that might be useful for simple calculations, I expect it would
simply get in the way and slow things down for larger, more complex
calculations.
Alas I don't think there's any
>>I'd like to see every number bundled with a "precision" attribute.
>That's not what I call a high-level language feature. People don't
>want to think about that, nor about machine-level precision issues.
>See REXX.
>In fact, I'd rather to see a painless and transparent int->float->bignum
>
>I'd like to see every number bundled with a "precision" attribute.
That's not what I call a high-level language feature. People don't
want to think about that, nor about machine-level precision issues.
See REXX.
In fact, I'd rather to see a painless and transparent int->float->bignum
autocon
Exactly. We need a nondestructive slice. Some short piece of
syntax which expands
for [my](list of vars) (big list){ ... }
to
my @uniquelynamedcopy = (big list);
while ( [my](list of vars) = splice(@u15y,0,(length of list of vars))){ ... }
I think the absence o
At 12:57 PM 8/29/00 -0500, David L. Nicol wrote:
>I'd like to see every number bundled with a "precision" attribute. It's
>a holdover from when I was heavily into chemistry.
Some of the other RFCs on the list also appear to have been triggered the
same way.
Oh, wait...
:-)
--
Peter Scott
Pac
Steve Simmons wrote:
> IMHO the code
>
> $a = '3.14'; # from reading a file
> $b = '3.1400'; # from user input
> if ($a == $b) { ... }
>
> should see the two args being tested in numeric context, do the numeric
> casting, get floats, and do a floating compare. Durned if I know what
At 12:43 PM 8/29/00 -0400, Steve Simmons wrote:
>On Mon, Aug 28, 2000 at 04:10:01PM -0400, Eric Roode wrote:
> > Peter Scott wrote:
> > >Graham Barr once allowed as how he thought it would be neat if you
> could say
> > >
> > > for my($x, $y, $z) (@list) { ... }
>
>I too am pushing for this f
On Mon, Aug 28, 2000 at 04:10:01PM -0400, Eric Roode wrote:
> Peter Scott wrote:
> >Graham Barr once allowed as how he thought it would be neat if you could say
> >
> > for my($x, $y, $z) (@list) { ... }
I too am pushing for this feature, to the point where I'm considering
an rfc on the topic
On Tue, Aug 29, 2000 at 09:21:32AM -0400, Eric Roode wrote:
> I'm not seeing an earth-shattering advantage of:
>
> for my($k,$v) (%hash)
> over
> while(my($k,$v) = each %hash)
>
> AFAICT, they act the same, just look a little different.
> Eight characters difference, c
On 27 Aug 2000, Perl6 RFC Librarian wrote:
> With a here doc print <
On 27 Aug 2000, Perl6 RFC Librarian wrote:
Don't know if anyone's picked this up or not, but I think it was in the
first
version, too.
> =head1 ABSTRACT
>
> With a here doc print < text of the here doc, is processed verbatum. This results in the terminator
> sticking out in the body of the doc
Graham Barr wrote:
>Maybe not with 3 variables, but how many people do
>
> my %hash = @_;
> { ... }
>
>so that they can process named arguments ?
>
>Having this would remove the need for the hash assignment. Also it hash been
>suggested that it could potentially replace each
>
> { ... }
I'm n
On Tue, 29 Aug 2000 20:21:39 +0800, Kenneth Lee wrote:
>oday this just came up to my mind, we could have a pragma that disable
>`autovivification' of hash and array keys. Consider the follow code snippet:
>
> @arr = ( 0..9 );
> %hash = ( a=>1, b=>2 );
>
> {
>no autovivify;
>$arr{10}+
dear all,
today this just came up to my mind, we could have a pragma that disable
`autovivification' of hash and array keys. Consider the follow code snippet:
@arr = ( 0..9 );
%hash = ( a=>1, b=>2 );
{
no autovivify;
$arr{10}++; # both are
$hash{c}--; # fatal
}
this way
Tom Christiansen <[EMAIL PROTECTED]> writes:
> >Object-oriented features were added to Perl with version 5, and in many
> >ways still appear somewhat "tacked on", with perhaps undue respect
> >for the Old Ways of Perl 4.
>
> [NB: This is not a serious missive.]
>
> Hey, that Perl uses package
Nathan Wigner, disguised as Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
[...]
Gut feeling, I don't like this proposal. Examples coming up.
> Increases in namespace are basically always beneficial.
>
> =head2 Potential Problems
>
> This approach is not without its problems. These need to b
On Mon, 28 Aug 2000 20:26:41 -0700, Nathan Wiger wrote:
> foreach (@str) { print "Got it" if match /\w+/, @str;
> if (/\w+/) { $gotit = 1 };
> }
> print "Got it" if $gotit;
>
>Now if DWIM just worked for email as well... ;-)
You mean, like grep?
print "Got it"
87 matches
Mail list logo
