On Wed, 20 Sep 2000 15:16:20 -0600, Tom Christiansen wrote:
>>That was my second thought. I kinda like it, because //s would have two
>>effects:
>
>> + let . match a newline too (current)
>
>> + let /$/ NOT accept a trailing newline (new)
>
>Don't forget /s's other meaning.
I gather you're talki
>I gather you're talking about //s making perl ignore the setting of $*.
>You're right, I didn't know that. But I doubt if it's that important,
>this variable already has been marked as deprecated since Perl5 came
>out, about 5 years ago. It's a good candiadte to be removed in Perl6.
Agreed.
>My
On Thu, Sep 21, 2000 at 10:59:19AM -0700, Steve Fink wrote:
> For lexicals, a use without a declaration makes no sense, because
> variables default to global (non-lexical). A use without an
> initialization is of arguable utility, because your defined() tests may
> already be intended to check fo
Bart Lateur:
> >If there are no objections, I will freeze this in twenty-four hours.
>
> Oh, I have a small one: I feel that this pseudo-random salt should NOT
> affect the standard random generator. I'll clarify: by default, if you
> feed the pseudo-random generator with a certain number, you'l
Daniel Chetlin wrote:
>
> On Wed, Sep 20, 2000 at 07:20:44PM -0700, Steve Fink wrote:
> > % perl -le '$x = 3; eval "\$x++"'
> > (no warning issued)
>
> [~] $ perl -wle'$x = 3; eval "\$x++"'
> Name "main::x" used only once: possible typo at -e line 1.
Doh! Thanks.
> "BL" == Bart Lateur <[EMAIL PROTECTED]> writes:
BL> On 21 Sep 2000 03:55:21 -, Perl6 RFC Librarian wrote:
>> Eliminate dump() function
>> Get rid of it completely.
BL> I think that, for the rare occasions people want this functionality, one
BL> of the many O (B) modules shoul
On Thu, 21 Sep 2000, Mark-Jason Dominus wrote:
> And the problem you describe is not really a problem. There has never
> been any guarantee that a program would produce the same sequence of
> random numbers after a change to the Perl binary.
> random numbers after a change to the Perl binary. M
Eric Roode wrote:
>
> Steve Fink, via the Perl6 Librarian, wrote:
> >=head2 EXAMPLE
> >
> >1 my ($x, $y, $z, $r);
> >2 $z = 1;
> >3 f(\$r);
> >4 my $logfile = "/tmp/log";
> >5 $x = 1 if cond();
> >6 print $x+$y;
> >7 undef $z;
> >8 print $z;
> >
> [...]
> >No warni
On 21 Sep 2000 03:55:21 -, Perl6 RFC Librarian wrote:
>Eliminate dump() function
>Get rid of it completely.
I think that, for the rare occasions people want this functionality, one
of the many O (B) modules should offer it, at least in spirit.
--
Bart.
Michael Fowler wrote:
>
> Ok, at this point I'm trying to clear up misunderstandings. I believe you
> know where I stand with relation to your RFC.
Thanks, you caught several of my mistakes.
>
> On Wed, Sep 20, 2000 at 06:41:52PM -0700, Steve Fink wrote:
> > Michael Fowler wrote:
>
> > > Exc
Tom Christiansen <[EMAIL PROTECTED]> wrote:
>=item perl6storm #0016
>
>object as scope/namespace? see python. it's danged clean
>there in that you can now implement safe trivially.
>don't have to keep inventing crazy overloads.
>
Yes, this would be great!
>=item perl6storm #0025
>
>Make -T t
Russ Allbery wrote:
> I'm not overlooking it; I just don't agree with you. There *is* a
> difference.
You are certainly welcome to not agree with me. And if you didn't overlook
it, that is fine.
In my opinion, which you probably will also not agree with, attempting to
toggle between the curre
Greg Boug wrote:
> Apologies if these comments have already been noted...
>
> > my $PI : constant = 3.1415926;
> > my @FIB : constant = (1,1,2,3,5,8,13,21);
> > my %ENG_ERRORS : constant = (E_UNDEF=>'undefined',
E_FAILED=>'failed');
> >
> > Constants can be lexically or globally scoped (or a
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 05:35 PM 9/21/00 -0400, Uri Guttman wrote:
>> i proposed some of that in my rfc47 (universal async i/o). at the perl
>> level you need a delivery interface as with events.
DS> I'm not really worried about the perl level for th
On Thu, 21 Sep 2000, you wrote:
> This one-liner is a complete perl extension:
>
> perl -e 'print add(2,2);use Inline C=>"int add(int x,int y){return
> x+y;}"'
I haven't written any XS myself, but I was under the impression that one
problem with it is that what you write an extension in (XS
On 19 Sep 2000 19:41:20 -, Perl6 RFC Librarian wrote:
>Perl should come distributed with more modules.
I know of people/sites where installing the whole lot of Perl just to
run a tiny script, is not acceptable as an option.
Not everyone is a developer.
--
Bart.
On Thu, 21 Sep 2000, Nathan V. Patwardhan wrote:
> I don't think that the documentation should be removed from the core
> distribution, BUT I do think that there should be an "easter egg" that
> allows people to build a Perl distribution without documentation or
> whatever else they choose. Ther
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Lazily evaluated list generation functions
=head1 VERSION
Maintainer: Jeremy Howard <[EMAIL PROTECTED]>
Date: 10 Aug 2000
Last Modified: 22 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 81
Ve
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Arrays: transpose()
=head1 VERSION
Maintainer: Jeremy Howard <[EMAIL PROTECTED]>
Date: 22 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 272
Version: 1
Status: Developing
=head1 ABSTRACT
It
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Internal representation of Pseudo-hashes using attributes.
=head1 VERSION
Maintainer: Michael Maraist <[EMAIL PROTECTED]>
Date: 27 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 273
Version: 1
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Regular Expression Special Variables
=head1 VERSION
Maintainer: Uri Guttman <[EMAIL PROTECTED]>
Date: 25 Aug 2000
Last Modified: 22 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 158
Version:
Damian Conway <[EMAIL PROTECTED]> writes:
> I didn't see any mention of my plea that C should pass the
> original variable being tied as one of its arguments. :-(
>
> E.g.:
>
> sub ReadOnly::TIESCALAR {
> my ($class, $original, @otherargs) = @_;
> bless {
>
Damian Conway <[EMAIL PROTECTED]> writes:
> Thanks for getting this RFC together, Piers.
>
> A few comments:
>
> * I suggest you remove my alternative C<:must(Foo)> suggestion.
> It's too ugly to live, inless you just want to use it as a
> scare tactic to encourage Lar
Doh! Don't read email for two days and look what happens. Its like
going on vacation and leaving the iron on.
Just FYI, the main thrust of the RFC is "More Modules". All the stuff
about multiple distributions and installation options is tangental and
will be dropped (or split off into another
On Wed, 20 Sep 2000, Nathan Wiger wrote:
>my int ($x, $y), char $z; # mix classes
>my int ($x, $y) :64bit, char $z :long; # and attrs
my (int ($x, $y), char $z);
my (int ($x, $y) :64bit, char $z :long);
--
Bryan C. Warnock
([EMAIL PROTECTED])
On Wed, Sep 20, 2000 at 10:08:09PM -0700, Glenn Linderman wrote:
> Russ Allbery wrote:
>
> > Why on earth would you want to do this in real code?
>
> I wouldn't, of course. This is just a demonstration that I want both
> semantics available concurrently.
If you are not going to use it, why imp
>How can you convince anyoone if you say you would not use it. For any feature
>enhancement to perl, unless there is a strong case for how it makes
>the labguage easier and better it is just not going to happen.
It's not as though Tim Bunce has been hollering for this, which is a
bad sign.
--to
On Thu, Sep 21, 2000 at 03:38:50AM -0400, Michael G Schwern wrote:
> On Thu, Sep 21, 2000 at 03:54:27AM -, Perl6 RFC Librarian wrote:
> > =head1 IMPLEMENTATION
> >
> > Dunno. With my vague understanding of the existing code and hash
> > tables in general:
>
> I believe the main reason why ha
Thanks, Paris, for your intervention, although I fear it was too late.
Well, since Tom claims to have put me in his kill file, he may never see
this. But for the record...
Tom Christiansen wrote:
> >Can't we all just play nice?
>
> Apparently not. Several of us attempted to explain why this
On 20 Sep 2000, Russ Allbery wrote:
> About the only piece of code of mine that this would affect are places
> where I use ++ on an undef value, and that's not a bad thing to avoid as a
> matter of style anyway (usually I'm just setting a flag and = 1 would work
> just as well; either that, or it
< Russ:
>> About the only piece of code of mine that this would affect are places
>> where I use ++ on an undef value, and that's not a bad thing to avoid as a
>> matter of style anyway (usually I'm just setting a flag and = 1 would work
>> just as well; either that, or it's easy enough to explic
On Thu, Sep 21, 2000 at 03:38:59AM -0600, Tom Christiansen wrote:
> > > Could the prototype people please report whether Tim Bunce's issues with
> > > prototypes have been intentionally/adequately addressed?
>
> >I'm not a prototype person (in fact RFC 128 makes it a hanging offence
> >to us
Nathan Wiger <[EMAIL PROTECTED]> writes:
> It seems potentially useful to be able to say:
>
>my Dog, Cat $fluffy;
>
> As a way to say "$fluffy can be either a Dog or a Cat". Since variables
> are prefixed, anything comma-separated up to the variable is an
> alternate class for that variable:
On Wed, 20 Sep 2000 12:30:26 -0600, Tom Christiansen wrote:
>$a = undef;
>
>You have initialized it to undef.
>Solution:
>
>Remove all references from the language to defined and undef.
Quite the reverse.
Simply assume that uninitialized variables in Perl simply don't exist,
that all v
=head1 NAME
perl6storm - tchrist's brainstorm list for perl6
=head1 DESCRIPTION
I'm going away for a long, long time, way past the RFC deadline.
Here is my file of notions I've brainstormed over the last few
weeks. Some have been covered in other RFCs. Many haven't. Most
could use some kicki
=item perl6storm #0106
Safe "signals"! (not syssigs,really)
On Wed, 20 Sep 2000, Damian Conway wrote:
> This RFC proposes the builtin functions that return a large number of
> values in an array context should also detect hashref contexts (see RFC
> 21) and return their data in a kinder, gentler format.
You may want to add a reference to the various exist
> > Could the prototype people please report whether Tim Bunce's issues with
> > prototypes have been intentionally/adequately addressed?
>I'm not a prototype person (in fact RFC 128 makes it a hanging offence
>to use that confusing word in connection with parameter lists! ;-)
>Could someone
On Thu, 21 Sep 2000, Tom Christiansen wrote:
> < Philip:
>
> >$seen{$word} = (exists $seen{$word}) ? 1 : $seen{$word} + 1;
>
> er, flip that.
Er, yes. Thanks.
> Larry wrote (in Camel-3) that
>
> ...the autoincrement will never warn that you're using undefined values,
> because au
Nathan Wiger <[EMAIL PROTECTED]> writes:
> > * The new C keyword would be unnecessary if *package
> > specifications* could take attributes:
> >
> > interface Fetcher;
> >
> > would then become:
> >
> > package Fetcher : interface;
>
Nathan Wiger <[EMAIL PROTECTED]> writes:
> By specifying "use interface" explicitly, you can make sure that your
> class follows the interface spec. Otherwise, you rely on other classes
> in the hierarchy above you doing so, and then you indirectly inheriting
> from that interface. So "use interf
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> =head1 ABSTRACT
>
> Currently, Perl 5 makes a distinction between routines called in the
> indirect object vs. function form:
>
>$r = new CGI; # CGI->new
>$r = new CGI (@args); # CGI->new(@args)
>$r = new(CGI @args); # mai
Both RFC 168 & 267 complain about the inability to override builtins. What
if p6 simply require all user defined functions to be called using the &func
syntax, and that builtins require the bareword syntax? This way any builtin
could be overridden and it would be immediately recognizable as an
ove
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, Fre
Ed Mills wrote:
> These would be perlish, nice, terse, succint, and economical:
>
<...>
>
> ($i, $i, $k) += 2;
>
>@nums = 10 * @nums;
>
These are both covered by RFC 82.
From: Michael G Schwern [mailto:[EMAIL PROTECTED]]
>
> Doh! Don't read email for two days and look what happens. Its like
> going on vacation and leaving the iron on.
Speaking of which, I just re-read my previous email, and I want apologize
for contributing to the flamebait. Sorry. Hopefully t
On Thu, Sep 21, 2000 at 09:08:49AM -0500, Garrett Goebel wrote:
:
: I share Tom's view here. I think it would be a bad idea to distribute the
: source tarball for the Core Perl Distribution without documentation. Has
: anyone made a case for the size of download issue? I was under the possibly
:
>I don't think that the documentation should be removed from the core
>distribution, BUT I do think that there should be an "easter egg" that
>allows people to build a Perl distribution without documentation or
>whatever else they choose. There have been times that I've
>wanted/needed to build a
On Thu, 21 Sep 2000, Michael G Schwern wrote:
> Sounds like a seperate RFC. Like I said, I want to reverse some of
> the philosophies that have kept things like LWP out of the core for so
> long.
The differing timescales of development by the myriad different authors
involved has always been on
On Thu, Sep 21, 2000 at 12:23:25PM +0200, Bart Lateur wrote:
> On 19 Sep 2000 19:41:20 -, Perl6 RFC Librarian wrote:
> >Perl should come distributed with more modules.
>
> I know of people/sites where installing the whole lot of Perl just to
> run a tiny script, is not acceptable as an option
On Thu, Sep 21, 2000 at 10:45:05AM +0100, Piers Cawley wrote:
> Whoa Nellie. When did we get prototyping for methods.
We've had prototyping (context coercing) for methods as long as we've
had them for "ordinary" subroutines.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
>We've had prototyping (context coercing) for methods as long as we've
>had them for "ordinary" subroutines.
Sure -- they just don't work.
Method calls are indirect function calls. As such, they are not
resolved until run time. Context coercion, however, is set at
compile time--if at all.
--
Jonathan Scott Duff <[EMAIL PROTECTED]> writes:
> On Thu, Sep 21, 2000 at 10:45:05AM +0100, Piers Cawley wrote:
> > Whoa Nellie. When did we get prototyping for methods.
>
> We've had prototyping (context coercing) for methods as long as we've
> had them for "ordinary" subroutines.
We have? Are
> =item perl6storm #0064
>
> Do something about microsoft's CRLF abomination.
I think for the case of Microsoft C++ used for the Win32 port, everyone
would be happy if Perl's sysopen, sysread, etc. did not require binmode.
Unfortunately, Microsoft made the decision very early on in its C/C++
dev
On Wed, 20 Sep 2000, Steve Fink wrote:
> 1 my ($x, $y, $z);
> 2 $z = 1;
> 3 my $logfile = "/tmp/log";
> 4 $x = 1 if cond();
> 5 print $x+$y;
> 6 undef $z;
> 7 print $z;
>
> --> use of uninitialized variable $y in line 5 (compile time)
> --> possible use of uninitialized variable $x in line 5 (
At 02:39 AM 9/21/00 -0700, Glenn Linderman wrote:
>Thanks, Paris, for your intervention, although I fear it was too late.
>
>Well, since Tom claims to have put me in his kill file, he may never see
>this. But for the record...
>
>Tom Christiansen wrote:
>
> > >Can't we all just play nice?
> >
> >
On Wed, 20 Sep 2000, Eric Roode wrote:
> foo();
> print $x;
>
> Generate a warning, or not? Which one? Remember, foo() may initialize $x.
My suggest (FWIW) would be that, if there is no execution path
which leads to $x being defined in the second line, then a "Use of
uninit'
Webmaster wrote:
> Both RFC 168 & 267 complain about the inability to override builtins. What
> if p6 simply require all user defined functions to be called using the &func
> syntax, and that builtins require the bareword syntax?
Uh, how does that result in overridability?
Sounds to me more lik
> "Michael" == Michael G Schwern <[EMAIL PROTECTED]> writes:
Michael> On Thu, Sep 21, 2000 at 03:55:21AM -, Perl6 RFC Librarian wrote:
>> Eliminate dump() function
Michael> I didn't even know it existed.
I do, every time I forget to hit the shift key around certain invocations
of Data::
Steve Fink, via the Perl6 Librarian, wrote:
>=head2 EXAMPLE
>
>1 my ($x, $y, $z, $r);
>2 $z = 1;
>3 f(\$r);
>4 my $logfile = "/tmp/log";
>5 $x = 1 if cond();
>6 print $x+$y;
>7 undef $z;
>8 print $z;
>
[...]
>No warning is issued for C<$r> because any variable whose
Glenn Linderman wrote:
>
> If they are the same, then you can't tell the different between a variable
> that is yet uninitialized, and one that has been read in from the database,
> containing a NULL. In my mind, that is horribly confusing.
Since this is a theoretical argument -- as evidenced b
Glenn Linderman wrote:
> ASCII, a standard that long predates Perl, defines the term NUL, not NULL, to refer
> to a null byte or null character.
Now, that's not accurate either. "NUL" is simply a normalized form of "null",
because all the ASCII special characters have three upper-case letter n
>Now, that's not accurate either. "NUL" is simply a normalized form of "null",
>because all the ASCII special characters have three upper-case letter names.
>There is no doubt that the ASCII guys meant "null" by this.
All other matters aside, kindly consider this simple one: If ever
you thought
From: Garrett Goebel [mailto:[EMAIL PROTECTED]]
>
> Hmm. Might want to be a bit more fine grained. How about the heretical
> option to strip pod and comments from the standard library?
So this would break any code which interacts with pod: Pod::Usage, perlman,
perlhelp, etc. Which I suppose just
>So this would break any code which interacts with pod: Pod::Usage, perlman,
>perlhelp, etc.
NB: perlhelp == perlman with a particular metapage named perlhelp,
which knows to search the pod library linewise.
>Which I suppose just adds weight to the don't go there,
>highly discouraged ultimatum.
On 19 Sep 2000, Chaim Frenkel wrote:
> > "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
>
> DC> But I'm *never* going to take out ^0. Having ^1 mean $_[0] is Just
> DC> Plain Wrong.
>
> Though I see your point. I'm not sure how many would make the connection
> between ^1 and $_[0].
>
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Arrays: merge() and unmerge()
=head1 VERSION
Maintainer: Jeremy Howard <[EMAIL PROTECTED]>
Date: 10 Aug 2000
Last Modified: 21 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 90
Version: 4
St
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Arrays: part and flatten
=head1 VERSION
Maintainer: Jeremy Howard <[EMAIL PROTECTED]>
Date: 10 Aug 2000
Last Modified: 21 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 91
Version: 4
Status:
=head1 VERSION
Reply-To: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Arrays: Add reshape() for multi-dimensional array reshaping
=head1 VERSION
Maintainer: Jeremy Howard <[EMAIL PROTECTED]>
Date: 24 Aug 2000
Buddha Buck wrote:
> >
> > @x = 3 * $y[|i];
> >
> >It's not as clean as @x = 3 * @y, but it is cleaner context-wise.
>
> And one could argue that:
>
> @x = map 3*^_, @y;
>
> is cleaner yet...
PDL already allows $x = 3*$y
why step backwards?
KArl
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Arrays: Overview of multidimensional array RFCs (RFC 203 through RFC 207)
=head1 VERSION
Maintainer: Jeremy Howard <[EMAIL PROTECTED]>
Date: 8 Sep 2000
Last Modified: 21 Sep 2000
Mailing List: [EMAI
Ilya Zakharevich wrote:
> As shipped: no. But if this is made a primitive (which I would not
> like), then the only change which is needed is to make the
> tie::multi::range() token to be followed by 3 numbers.
>
> [Aside: Why not make ternary-range operator into 10 :: 20 :: 2 ?]
That would wor
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Arrays: Notation for declaring and creating arrays
=head1 VERSION
Maintainer: Jeremy Howard <[EMAIL PROTECTED]>
Date: 8 Sep 2000
Last Modified: 21 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Arrays: New operator ';' for creating array slices
=head1 VERSION
Maintainer: Jeremy Howard <[EMAIL PROTECTED]>
Date: 8 Sep 2000
Last Modified: 21 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Arrays: Apply operators element-wise in a list context
=head1 VERSION
Maintainer: Jeremy Howard <[EMAIL PROTECTED]>
Date: 10 Aug 2000
Last Modified: 21 Sep 2000
Mailing List: [EMAIL PROTECTED]
Num
Karl Glazebrook wrote:
>
> Buddha Buck wrote:
> > >
> > > @x = 3 * $y[|i];
> > >
> > >It's not as clean as @x = 3 * @y, but it is cleaner context-wise.
> >
> > And one could argue that:
> >
> > @x = map 3*^_, @y;
> >
> > is cleaner yet...
>
> PDL already allows $x = 3*$y
>
> why step back
At 03:26 PM 9/21/00 -0400, Karl Glazebrook wrote:
> > > Finally as an overload expert what do you think about the proposals
> > > to make arrays overloadable objects so one can say things like:
> > >
> > > @x = 3 * @y;
>I can see that allowing expressions on @x would require considerable
>chan
At 03:35 PM 9/21/00 -0400, Buddha Buck wrote:
>At 03:26 PM 9/21/00 -0400, Karl Glazebrook wrote:
>
>> > > Finally as an overload expert what do you think about the proposals
>> > > to make arrays overloadable objects so one can say things like:
>> > >
>> > > @x = 3 * @y;
>
>What do you think of:
>
On 20 Sep 2000 21:37:03 -, Perl6 RFC Librarian wrote:
>Bart Lateur: '()=' is not perfect. It is also butt ugly. It is a "dirty hack".
Please don't hold this against me!
I was arguing for a cleaner looking generic alternative for "()=", the
now defunct list() operator.
I do think that just
At 16:09 -0700 2000.09.19, Russ Allbery wrote:
>Was there any resolution as to how one obtains the offset between the
>system clock and the Unix epoch clock on a platform like Mac where
>apparently the system clock is in local time and it may be difficult to
>determine the time zone of the system?
> "AG" == Alan Gutierrez <[EMAIL PROTECTED]> writes:
AG> Just like the the regex match placeholders, positional placeholders begin
AG> with ^1 so that ^1 == $_[0]. If this doesn't make sense to it is
AG> probably because you are new to Perl and are not familiar with regular
AG> expressions, b
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Arrays: Efficient Array Loops
=head1 VERSION
Maintainer: Buddha Buck <[EMAIL PROTECTED]>
Date: 8 Sep 2000
Last Modified: 21 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 207
Version: 2
Stat
Christian Soeller wrote:
> Karl Glazebrook wrote:
> > Buddha Buck wrote:
> > > >
> > > > @x = 3 * $y[|i];
> > > >
> > > >It's not as clean as @x = 3 * @y, but it is cleaner context-wise.
> > >
> > > And one could argue that:
> > >
> > > @x = map 3*^_, @y;
> > >
> > > is cleaner yet...
> >
>
Bart Lateur wrote:
> Hmm... the problem is, I think, that array references and ordinary
> scalars are both scalars.
>
That's true, but they're scalars with different interfaces. In particular,
an array ref can be dereferenced and provides an array in doing so. If an
index can do this, then it's a
On Thu, Sep 21, 2000 at 03:26:39PM -0400, Karl Glazebrook wrote:
> > [Aside: Why not make ternary-range operator into 10 :: 20 :: 2 ?]
>
> That would work. My point is that having a stride is a fundamental
> feature in other array languages (IDL, Matlab, PDL) and would be
> useful in the perl cor
At 05:35 PM 9/21/00 -0400, Uri Guttman wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> DS> I would *really* like perl's I/O system to do async reads and
> DS> writes to disk files whenever possible. That'd let us get another
> DS> burst of speed in some spots, particularl
Apologies if these comments have already been noted...
> my $PI : constant = 3.1415926;
> my @FIB : constant = (1,1,2,3,5,8,13,21);
> my %ENG_ERRORS : constant = (E_UNDEF=>'undefined', E_FAILED=>'failed');
>
> Constants can be lexically or globally scoped (or any other new scoping
> lev
Glenn Linderman <[EMAIL PROTECTED]> writes:
> Philip Newton wrote:
>> Having $seen{$word}++ turn $seen{$word} to undef is bad,
It doesn't "turn it to undef"; if you're using tristate semantics, it
leaves it as undef, because those are the semantics you've selected for
undefined values.
>> if (u
> my/our @array :hashsyntax;
>
> would hide the definition of %array in the same way that
>
> my/our %array
>
> would hide a prior definition of %array. And references to %array
> would thenceforth actually be references to the keyed array @array.
I can see massive confusion from th
Eric Roode wrote:
>
> Allow me to throw another log on the fire:
>
> my $x;
> if (something)
> {
> $x = 1;
> }
> my $y = $x;
>
> This would give a compile-time warning under your RFC, warning the
> user of a possibly uninitialized $x. Okay. Next:
Yes.
> my $x;
On Thu, 21 Sep 2000, Andy Dougherty wrote:
> On Thu, 21 Sep 2000, Nathan V. Patwardhan wrote:
>
> > I don't think that the documentation should be removed from the core
> > distribution, BUT I do think that there should be an "easter egg" that
> > allows people to build a Perl distribution with
> "MGS" == Michael G Schwern <[EMAIL PROTECTED]> writes:
MGS> The problem of production machines vs devel machines isn't such a big
MGS> deal. Production machines generally have plenty of space and only one
MGS> copy of Perl.
Sez You.
I've got installations where I have to hunt around to f
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
TC> +---+
TC> | Permit me to repeat: if you remove the documentation, you will no |
TC> | longer have a functioning Perl distribution. |
TC>
Glenn Linderman <[EMAIL PROTECTED]> writes:
> In my opinion, which you probably will also not agree with, attempting
> to toggle between the current undef semantics and tristate semantics is
> like trying to stuff three values into one bit.
I do understand the argument. I just see confusion eit
Michael Maraist wrote:
> > my/our @array :hashsyntax;
> >
> > would hide the definition of %array in the same way that
> >
> > my/our %array
> >
> > would hide a prior definition of %array. And references to %array
> > would thenceforth actually be references to the keyed array @arr
On 20 Sep 2000 04:06:02 -, Perl6 RFC Librarian wrote:
>Ilya Zakharevich brought up the issue of a potential problem with
>objects which use blessed list references as their internal structure,
>and their use as indices. Given a Bignum class, which stores its
>(external) value internally as a
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Subroutines : Pre- and post- handlers for subroutines
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 21 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 271
Version: 1
Dave Storrs wrote:
>
> On Wed, 20 Sep 2000, Eric Roode wrote:
>
> > foo();
> > print $x;
> >
> > Generate a warning, or not? Which one? Remember, foo() may initialize $x.
>
> My suggest (FWIW) would be that, if there is no execution path
> which leads to $x being defined in the
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Make constants look like variables
=head1 VERSION
Maintainer: Jeremy Howard <[EMAIL PROTECTED]>
Date: 10 Aug 2000
Last Modified: 21 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 83
Version: 3
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
crypt() default salt
=head1 VERSION
Maintainer: Mark Dominus <[EMAIL PROTECTED]>
Date: 11 Sep 2000
Last Modified: 21 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 208
Version: 3
Status: Dev
1 - 100 of 114 matches
Mail list logo
