$a[$i][$j][$k] or $a[$i,$j,$k]
The second one has no useful meeting, "," is just an operator which
does nothing much useful in this context.
Not true, at least not in the Perl I know. :-) Here's a description of
what these do in Perl just to clarify:
$a[0][1][2]; # get a single
Doug Hunt wrote:
What I meant to say (but failed, alas) was that I support the idea for a
new perl variable type called compact array:
$foo -- scalar
@foo -- array
%foo -- hash
^foo -- compact array (or whatever notation)
Given this notation, you could have hashes of compact
Baris wrote:
Hi,
^foo = ([1, 2], [3, 4]); # I know, it's taken, I helped :-)
$foo[0,0];# uh-oh
Then adding a new fundamental type and syntax is not only unnecessary,
but silly.
Why do you think that individual elements are perl scalars?
To avoid anyone
[EMAIL PROTECTED] wrote:
I disagree. You end up with a situation where some
@a * @b;
are in scalar context, some not.
No, everything would be in a scalar context. If you used tie() to
specially tie a variable, then you might be able to overload +, *, -,
etc, but this is no different
Nathan Torkington wrote:
Actually, the only refinement I'd like to see is that boolean operators
(==, , ||) be excepted from the distributive rule.
This is to permit:
if (@a == @b) # shallow comparison
and
@a = @b || @c;# @a=@b or @a=@c; # ish
Yeah, I
Jeremy Howard wrote:
RFC 203 defines a :bounds attribute that defines the maximum index of each
dimension of an array. RFC 206 provides the syntax @#array which returns
these maximum indexes. For consistancy, the arguments to reshape() should be
the maximum index of each dimension. A
This RFC proposes a support of a situation when a more-knowledgable module may
steal overloading from a less-knowledgable module or visa versa;
What if both modules have this :override bit set at the same time? Does
the second one still win? Or does the first one win again?
Either way I'm not
The idea of interpolating a hash is cool... but is seperating each
pair by $/ really useful? A comma or $" sees to make more sense.
Yeah, I for one think %hashes should be interpolated exactly like
@arrays. It's simple and consistent.
-Nate
Sorry Nate--I know we thought we were on the same wavelength here, but it
looks like we weren't at all! Would you like me to redraft this for you, or
create a new RFC?
It's all yours. My brain is toast, and I'm totally RFC'ed out. The only
thing I care about is that the lists wind up on the
==
Either way I'm not sure it solves the problem; if each module asserts
that *they* are the smarter one then you either wind up with the same
situation you have now or even worse contention.
Bart Lateur wrote:
The problem is that
$name = "myarray";
@$name = (1,2,3);
print @$name[0,1]; # 1,2
Is very consistent currently. Change one and you have to change the
precedence and parsing of all symbolic refs.
You are suggesting to keep a weird precedence rule, just
Chris Nandor wrote:
just assume "All Perl core functions should return objects", and hence
the reason I wrote RFC 73. ;-)
And it would make me stop using Perl faster than your object method could
be resolved.
Is your concern one of?
1. Speed
2. Bloat
3. Excess burden on the
Nathan Wiger wrote:
I think we should definitely maintain this in UTC, since this is how
UNIX works natively. If we're standardizing on the UNIX epoch we should
standardize on UTC clock as well.
Blech. Now I'm not sure after re-reading the thread starting here:
http://www.mail-archive.com
How about this?
open '/etc/passwd'; # file
open '/usr/local/bin/'; # directory (note the trailing '/')
open 'ftp://ftp.perl.org/'; # ftp
open 'http://www.yahoo.com/'; # http
open 'ldap://ldap.bigfoot.com/';# ldap
I think
This is nutso... shall we open-ssh and open-telnet and
open-any_protocal_under_the_sun in the core?
Well, just because the hooks are there doesn't mean all the member
modules have to be in core. The idea would be, as Tom Hughes suggests:
That is if the core provides a way for modules to
# Open a remote webpage
$http = open http "http://www.perl.com/", GET;
^
1) The URL says that it's a http resource, so why do we have
to tell open to use a http handler?
a) Allows custom handlers:
open myhttp
And how do we make it easy to pass in a name to open?
In an email I sent to Jarkko off-list, I suggested this:
If we embedded full URI support into Perl, then people could write
portable scripts using URIs, or non-portable ones using native syntax.
*Internally*, both could be converted into
What does that mean? When the handler is invoked, what does it see?
$fh = open myhttp "http://www.perl.com", "fred", "barney";
Does that result in a call like this?
myhttp::open("http://www.perl.com", "fred", "barney");
Exactly. Or to be "more correct"
Sam Tregar wrote:
How is this better than File::Spec's approach?
File::Spec has the idea and representation dead on. However, the
interface is a pain; to write portable scripts you have to go through
some contortions.
With URI support, you still have to contort a little, but not as much.
So, what's so portable about file:// URLs again? How do they magically
know that //c/ means / on UNIX? What do they do with //z/?
This is only one example. I'm not sure it's the best way. It's
definitely not the only way. Chaim asked:
Or for that matter "file://u/frankeh/Projects" become?
Graham Barr wrote:
Create a new handle, like $DEFOUT. Then there would be no need
for selectsaver either as you would do the equiv. of
local($DEFOUT) = $newhandle;
Just submitted an RFC on this exact idea.
-Nate
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
Jon Ericson wrote:
I would want it to return @items:
@sorted = sort print @items;
I'd prefer a different name (tee?) and keep print as it is.
Pretty much all the stuff being discussed right now can be stuck in a
module:
package Print::Variations;
use Exporter;
@EXPORT =
[cc'ed on internals as FYI]
=item 36 (v1): Structured Internal Representation of Filenames
I think this should be discussed a good amount. I think URIs are cool,
but too much trouble for simple stuff. I don't want to have to write
"file:///etc/motd" everytime I want to address a file. Too
All-
This is an idea I've been chewing on for some time. RFC 14 proposes a
new syntax to open():
$FH = open dir "/usr/local/bin" or die "Badness: $!";
which is far different from the current open(). This is actually a more
flexible and consistent syntax, with a cool feature I just came
Glenn Linderman wrote:
I have a number of scripts that use this sort of facility, using push/shift
to populate/read the array "file". These could be made simpler and more
general by wrapping the array as a file.
Perhaps the open "handler" stuff could be used to implement this?
[ for those on -all or -objects this is gonna look real familiar :-) ]
All-
As Nat has mentioned on -meta, it's time to start wrapping things up. In
particular, I think the following "deadlines" should apply:
1. Any and all *new* RFC's should be submitted by Wednesday at the
absolute
Michael G Schwern wrote:
On Sun, Sep 17, 2000 at 05:35:47AM -, Perl6 RFC Librarian wrote:
$fo-untaint - Removes tainting from that data source
I can guarantee this will be abused and severely water down the
utility of taint mode.
Well, as Tom pointed out to me this already
Tom Christiansen wrote:
Scalars hold references to objects. Filehandles should, ultimately,
be objects, as should directory handles.
I haven't yet seen anybody yet propose bifurcating {file,directory}handles.
This would certainly be nice.
If I'm understanding what you mean, I believe
I'd rather see you drop (or footnote) the discussion of how the various
systems are going to map content among themselves, and focus more on
what the construct allows. For instance, returning to some of the
original implementation ideas, that the location information be passed
to the
We've only got 4 days left until the One True Deadline on this whole
thing. Please, go check this out:
http://dev.perl.org/rfc/overdue-perl6-language-io.html
And get your RFC's finished up. Remember: Oct 1st is a true deadline,
coming from the powers above, meaning if your RFC is not frozen by
you would do:
$sock = AIO::Open( Host = 'www.perl.org',
Port = 80 ) ;
Similarly for LWP you would just do:
$sock = AIO::Open( Url = 'http://www.perl.org' ) ;
$event = AIO::Open( Host = 'www.perl.org',
Port
You can have your cake, but not force us to eat it too...
Like $AUTOLOAD, $ME would be dynamically scoped:
The first time I saw the bareword "self" keyword I almost wet myself in
horror, but I would say that $AUTOLOAD is a disaster that should not be
repeated. And that's the way that this
/
=head1 TITLE
True Polymorphic Objects
=head1 VERSION
Maintainer: Nathan Wiger [EMAIL PROTECTED]
Date: 25 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 159
Status: Developing
=head1 ABSTRACT
Currently, using objects in numeric and string contexts
Nathan Torkington wrote:
Are you proposing making even "normal" scalar, hash, and array access
go through these methods? Wouldn't that slow everything way down?
Glad you brought this up, Nat!
I would say "yes and no". The reason I'd say this is because Dan S. and
the internals guys are
Please discuss this RFC on the -objects sublist. Thanks.
Matt, you should probably update the Mailist List to
perl6-language-objects for v2.
-Nate
Perl6 RFC Librarian wrote:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
OO
"Randal L. Schwartz" wrote:
That's my first gut reaction to this proposal. "If you like Python,
you know where to find it, but let us have some primitive data types
in Perl that act primitive so we can optimize things."
Well, we're on a border here. What this RFC is really referring to is
What, then, happens to the following code:
my Dog $spot;
if ($age 12) {
$spot = new Doberman();
} else {
$spot = new Corgi();
}
This is a tricky case that deserves a lot of attention, but not exactly
as written. Imagine this code block:
my int ($x, $y, $z) = (4, 5, 6);
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:
Michael G Schwern wrote:
Derived classes will never have to override a base's implementation,
and all member variables should be private, and everyone will always
use an accessor, and the UN will bring about world peace, and as long
as I'm wishing for a perfect world, I'd like a pony. ;)
All-
I've been toying with this for a while, and I'm looking for others'
input. I'm not RFC'ing it yet because (a) I already have 25 others to
maintain and (b) I'm not sure if this might be covered by "my sub" or
one of Damian's future RFC's.
Currently, there are two big problems in defining
private $hash{key};
private $hash{$key};
private $hashref-{key};
or to a hash slice:
private @hash{qw(_name _rank _snum)};
or to a complete hash (either directly, or via a reference):
private %hash;
private { _name = "demo", _rank =
Damian Conway wrote:
attr3 = [ALL]
It was (and is) a good suggestion. I suspect however that it should be
attr3 = [__ALL__]
Any consideration given to the :all export-like tag?
attr3 = [:all]# could be uppercase too
-Nate
Michael Fowler wrote:
=head3 Merge CTIESCALAR, CTIEHASH, and CTIEARRAY into CTIE
I'm not so sure about this.
I'm not either anymore. This will probably be removed from the next
version.
Instead, this RFC proposes that Ctie's operation become much more
fundamental, simply translating
Michael G Schwern wrote:
sub lock { print "Hello!" }
$trans = new Lock::Ness;
lock $trans; # $trans-lock
That's not right.
You're correct. Sorry for not double-checking my examples.
the same reasons I've already pointed out. You don't want adding a
method to a class to
use namespace 'Big::Long::Prefix';
my ::Class $object = ::Class-new;
Anyone mentioned that this:
$SHORT = 'Some::Huge::Obnoxious::Ridiculous::Term';
$SHORT-member;
$stuff = new $SHORT;
Already works? The only problem is that this:
$SHORT::stuff(@args);
Doesn't, but this
This topic is actually covered, albeit far less in-depth and lumped with an
unrelated change, by Nathan Wiger's RFC 103, just in case you weren't aware.
Yeah, I've got to split those up. I was trying cut down on the flood of
RFC's that poor Larry has to sift through :-(, but they are both
Nathan Wiger wrote:
use namespace 'Big::Long::Prefix';
my ::Class $object = ::Class-new;
Assuming repairing :: precedence is a reality I don't think this
proposal buys us anything.
backtracking...That being said, I'm not necessarily against it. I'm
just against bloat. I hadn't
=head2 The CBUILD method
=head3 The CREBUILD method
Hey! You left out the alternative names NEW / RENEW and BLESS / REBLESS
that we all like! :-(
-Nate
[added -io cross-post]
John Porter wrote:
Just MHO, but I don't think this is the kind of thing that should
go in the core. Just MHO.
I think I agree. Just to clarify, the only reason it's an RFC and not
just a Perl 5 module is because RFC 14 (the one on a new open()) relies
on a handler
Tom Christiansen wrote:
print "Today's weather will be $weather-temp degrees and sunny.";
So, the - operator is supposed to get expanded in dq strings, eh?
It already does, or at least appears to to users:
print "Today's weather will be $weather-{temp} degrees and sunny.";
How about also just ":access" to do both? It would seem to be the
most common case.
I was trying to conserve keywords, but I'm not opposed to this.
=head2 Mixing autoaccessors and real subs
I really don't see how this is necessary. If you have to write a
custom accessor, you might as
[From DBI-connect()]
# XXX this is inelegant but practical in the short term, sigh.
if ($installed_rootclass{$class}) {
$dbh-{RootClass} = $class;
bless $dbh = $class.'::db';
my ($outer, $inner) = DBI::_handles($dbh);
bless $inner = $class.'::db';
All-
As the sublist chair, I politely ask you to please table this
discussion. Time is running short and this is really a digression.
Glenn, if you have a proposal, please put one together in RFC format and
post it to -objects.
-Nate
All-
In an attempt to nudge things in the right direction (wrap-up), I've
gone through and made some specific comments on RFC's. These are my
opinions from monitoring the discussions on this list since its
inception. I do not claim to be infallible, but feel I have a pretty
good idea of what's
What sets Ruby apart is a clean and consistent
language design where everything is an object.
I like this part. Assuming I ever finish my last RFC I'd like Perl to
have embedded objects as well. The difference being Perl's wouldn't get
in the way, unlike Python's.
Of particular interest seems
This RFC proposes two new keywords -- Cprivate and Cpublic -- that limit
the accessibility of keys in a hash, and of methods.
I still think these should be attributes across the board:
my $hash{$key} : private = $val;
my @hash{qw(_name _rank _snum)} : public;
sub dostuff : private {
Damian Conway wrote:
The problem with specifying them as attributes is that I do not believe
there is any way (or even any proposed way) of applying attributes to
a hash entrie or a hash slice, nor is there any way of *retrospectively*
applying an attribute to a hash that has already been
Damian Conway wrote:
I didn't see any mention of my plea that Ctie should pass the
original variable being tied as one of its arguments. :-(
That's because it's a dumb idea!!
**Kidding!**
I forgot about this, sorry. I'll add it to the next version ;-)
my $x = 10;
tie
package Doggie;
sub isborn {
bless { @_ }, self; # ;-)
}
sub scratches ($\@;@) {
...
}
package Doggie::Cute;
use base 'Doggie';
use interface 'Pet';
# Our base class is 'Doggie', which does not use the 'Pet'
#
I'm kind of curious to know what you think would happen with the
following. I've commented where I'm confident...
interface Number;
sub TIESCALAR;
sub STORE;
sub FETCH;
package integer implements Number; # I really like this notation
Tangentially, yes, it is nice
[cc'ed to -regex b/c this is related to RFC 138]
Proposed replacements for m// and s///:
match /pattern/flags, $string
subst /pattern/newpattern/flags, $string
The more I look at that, the more I like it. Very consistent with split
and join. You can now potentially match on
if (/Time: (..):(..):(..)/) {
$hours = $1;
$minutes = $2;
$seconds = $3;
}
This then becomes:
/Time: (?$hours=..):(?$minutes=..):(?$seconds=..)/
This is more maintainable than counting the brackets and easier to understand
for a complex regex. And
Nathan Torkington wrote:
Hmm. This is exactly the same situation as with chomp() and somehow
chomp() can tell the difference between:
$_ = "hi\n";
chomp;
and
@strings = ();
chomp @strings;
Good point. I was looking at it from the general "What's wrong with how
@arrays are
Tom Christiansen wrote:
While I agree that /l is bad, I think going through the crap of "= () ="
is even worse. Does it work? Yes. But is it easily usable and fun, even
for non-experts? No.
Oh, for crying out loud--at some point, you have to stop tossing
rotting fish for the starving
Mark-Jason Dominus wrote:
RFC135: Require explicit m on matches, even with ?? and // as delimiters.
This one is along a different line from these two:
RFC138: Eliminate =~ operator.
RFC164: Replace =~, !~, m//, and s/// with match() and subst()
Which I could see unifying. I'd ask people
Mark-Jason Dominus wrote:
I think the reason this hasn't been done before it because it's *not*
quite straightforward.
Before everyone gets tunnel vision, let me point out one thing:
Accepting variables in tr// makes no sense. It defeats the purpose of
tr/// - extremely fast, known
Tom Christiansen wrote:
tr///e is the same as s///g:
tr/$foo/$bar/e == s/$foo/$bar/g
I suggest you read up on tr///, sir. You are completely wrong.
Yep, sorry. I tried to hit cancel and hit send instead. I'll shut up
now.
-Nate
I think it's cool too, I don't like the @^g and ^@G either. But I worry
about the double-meaning of the []'s in your solution, and the fact that
these:
/\m[...]...\M/;
/\d[...]...\D/;
Will work so differently. Maybe another character like ()'s that takes a
list:
/\m(,[).*?\M(,])/;
Richard Proctor wrote:
No ?] should match the closest ?[ it should nest the ?[s bound by any
brackets in the regex and act accordingly.
Good point.
Also this does not work as a definition of simple bracket matching as you
need ( to match ) not ( to match (. A ?[ list should specify for
It would be useful (and increasingly more common) to be able to match
qr|\s*(\w+)([^]*)| to qr|\s*/\1\s*|, and handle the case where those
can nest as well. Something like
listmatch this with
list
/list not this but
/list this.
I suspect this is going to need a ?[ and ?]
Mark-Jason Dominus wrote:
Larry said:
# Well, the fact is, I've been thinking about possible ways to get rid
# of =~ for some time now, so I certainly don't mind brainstorming in
# this direction.
That is in
[EMAIL PROTECTED]
which is archived at
I'm opposed to an obligation to replace m// and s///. I won't mind the
ability to give a prototype of "regex" to functions, or even
*additional* functions, match and subst.
As the RFC basically proposes. The idea is that s///, tr///, and m//
would stay, seemingly unchanged. But they'd
Simon Cozens wrote:
Looks great on scalars, but...
@foo =~ shift; # @foo = $foo[0] ?
@foo =~ unshift; # @foo = $foo[-1] ?
Yes, if you wanted to do something that twisted. :-) It probably makes
more sense to do something like these:
@array =~ reverse;
@vals =~ sort { $a =
Is $$ the only alternative, or did I miss more? I don't think I've even
seen this $$ mentioned before?
$$ is not a suitable alternative. It already means the current process
ID. It really cannot be messed with. And ${$} is identical to $$ by
definition.
I still like the idea of $$, as I
=item *
C\1 goes away as a special form
=item *
$1 means what C\1 currently means (first match in this regex)
=item *
${1} is the same as $1 (first match in this regex)
=item *
${P1} means what $1 currently means (first match in last regex)
Here's the big problem with this, and I
Kai Henningsen wrote:
1. Package variables $package::var, presumably you'd have to declare those
and the default would be
2. lexical variables,
Not bad, but I think #1 violates Laziness if I hear you right. Let's add
a "global" or "your" keyword to do this inside a package:
package
This message is intended to remind us all that the deadline for this
working group is _tomorrow_.
Not so fast!
This is not true anymore. I sent an email to K. requesting all the
current sublists be made permanent. She agreed. Here's the list of
*permanent* sublists:
-io = ALL I/O
Tom Christiansen wrote:
Perhaps you simply know inept C programmers.
Is there any other kind? ;-)
*Kidding*!
In C, something that
isn't declared auto or static is going to be global. Seeing no
scoping declarations, the C programmer who knows C will come to the
same conclusion as the
[EMAIL PROTECTED] wrote:
But we can run an experiment. Warnings can be made default for the
first few releases of Perl 6 and we'll see what happens. If it looks
good, leave them on. If not, shut them off. Unlike most other
features, this one doesn't have any serious backwards
True.
I wonder if we could change '=' to always quote the lhs, even if
prefixed by '$', '@', or '%' (maybe we should only enable this
behaviour inside parameter lists?) That would allow us to do this.
That's gonna take some digestion time.
In the meantime, is there a reason the
Er, I thought we were talking about setting named parameters, not
default values.
sub foo ($name = 'Fred', $age = 32) { # defaults
# do stuff with $name and $age
}
foo('Barney', 31); # Positional assignment
foo($age:31,
Chaim Frenkel wrote:
Why this limitation?
If the lvalue is a fundemental type (whatever that is) everything works
as if the lvalue were actually in place
sub foo { return $a }
foo =~ s///;# same as $a =~ s///;
This is not the type of lvalue sub that this RFC
Tom Christiansen wrote:
A main goal for Perl 6 is to make it faster, more compact, and lighter
weight. This means moving lots of former core functions into modules.
Andy D once posted something showing empirical evidence
that this hypothesis is in fact *FALSE*.
Ok. Perhaps I should
Chaim Frenkel wrote:
NW$old = assign($var, $val);
NW$old = assign($var) = $val;
NW$old = assign = $var, $val;
I don't think that the assigned values should be moved by perl into
the argument list.
You are reintroducing another version of the list flattening problem.
"Where
Tom Christiansen wrote:
But I will *not* relish typing
STDERR-print("darn")
Agreed. The day this is required is the day Perl stops becoming fun and
starts becoming C++.
No matter what, I think that any basic script should be able to be
written without any -'s.
One goal of my RFC was
Damian Conway wrote:
Nor I. That's why I'd advocate mandatory braces on indirect objects.
I'd rather:
print {STDERR} "darn"
any day.
Sorry, I'm way against that. If you're going to force that, then just
enforce:
STDERR-print("darn")
Same amount of typing.
Indirect objects
Johan Vromans wrote:
You can do that easily:
sub param {
my ($self, @rest) = @_;
$self-{aval} = @rest if @rest; # See note
lreturn $self-{aval};
}
I've been thinking about this for a couple days. The only problem I see
is that this doesn't allow me to do this:
Nathan Torkington wrote:
Turning Perl into a nagging harpie means that the really important
warnings will be ignored.
This line of thinking brought to you by Mark-Jason's excellent talk
on data typing.
I agree, and just read MJD's paper the other day (nice job, BTW), but
unfortunately
Michael G Schwern wrote:
I'm surprised there hasn't be a good overhaul of the prototyping
system proposeed yet. Your length() propsal wouldn't be the only
think that can't be prototyped. print() is the simplest example.
I think print should probably become something like what Eryq
=head2 Choice of notation
The placeholder notation has been chosen to be consistent with the
eisting Perl scalar notation (but using a ^ prefix rather than a $):
RoleScalar Placeholder
var analog
named
Damian Conway wrote:
That's it! I'm gonna take that whole section out and burn it!
;-)
$1 is the *only* place in Perl where an index starts at 1. *It's* the one
that's inconsistent. Fix *it*.
I'd love to. But we're stuck, unless we make a $CMD which holds what $0
currently holds, which I
Tom Christiansen wrote:
Mostly harmless. Right before raising the famous "Can't locate method
..." error, Perl should check to see if Cautoload is in effect. If so,
it should read the Cautoload.conf config file and ...
***LINEARLY READ A FLAT FILE!!?!?!***
I didn't get into the guts too
The AUTOGLOB subroutine should expect to take two parameters, the invocant,
and a second parameter specifying what type of item is being AUTOGLOBbed,
followed by - in the case of a sub - the sub's arguments. We suggest that
the second parameter should be a scalar value - 'scalar' for an
=head1 CHANGES
Comments received have been that it would be better to use AUTOSCALAR,
AUTOHASH etc instead of AUTOGLOB in the interests of encapsulation.
The argument being that if you only want to implement AUTO scalars in
your program, then doing:
Cif($type_of_thing eq 'scalar') {
Ariel Scolnicov wrote:
Unfortunately, this would mean your example above doesn't quite work.
One possibility is to say that $^T controls taint *checking*, but not
tainting itself[1]!
This is actually a good distinction that's worth some more discussion.
One could set the implementation so
C is, at times, less than logical. Witness the localtime fun: some of it's
zero-based, some of it's one-based, and some of it's -1900-based. All from the
same function. The localtime concept is needed, the localtime brain damage is
really not.
I agree completely. I take issue with changing
Wanted to get this out as an idea that could encompass lots of the
concerns I'm seeing about warnings and such:
=head1 TITLE
Warnings and Tainting should be reimplemented as pragmas.
=head1 VERSION
Maintainer: Nathan Wiger [EMAIL PROTECTED]
Date: 2 Aug 2000
Version: 1.0
Mailing-List: perl6
Warnings and Tainting should be reimplemented as pragmas.
What part of warnings(3) and perllexwarn(1) are you in disagreement with?
Not yet fully-versed on everything having todo with 5.6, appears I made
a bit of an oversight (i.e., as you mention 'use warnings' is already in
5.6)! So while
No: lists are the plural whatzitzes, containing zero or more singular
whatzitzes. They are ordered. Arrays hold lists.
I tend to agree with Tom's argument here. open() is kind of funny
anyways. Why couldn't it work like this, similar to FileHandle:
$fh = open $filename;
print $fh
1 - 100 of 396 matches
Mail list logo
