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
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
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
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
> "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
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
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
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
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;
> 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
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
> "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, particularly when slurping through
DS> files sequentially (which
(offlist)
If I had a qoute file for a raondom sig generator, this would surely be
added. :)
> Some languages like to have the compiler emit annoying messages to
> announce you forgot to include some pointless code whose only purpose
> is to stop the compiler from emitting the annoying message.
At 10:22 AM 9/21/00 -0500, Fisher Mark wrote:
> > =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, Mic
> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
PRL> If a handler changes one of the original arguments through the
PRL> aliases in its @_ array, those changes a passed on to subsequent
PRL> handlers and to the primary itself. For example:
PRL> pre tax_payable_on
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
TC> Ok, so you want message catalogues, and not solely on Perl but anything
TC> in the distribution. You should say that.
No. That is independent of what I'm suggesting. What I'm suggesting is
an enabler.
I've seen code that actually l
Buddha Buck wrote:
> Ok, let's see if I can make some sense of this...
Thanks for trying. I think you have.
> You want a singleton scalar datatype in addition to the exising scalar
> datatypes of strings, numbers, references, filehandles, and undef that
> represents an unknown value, similar i
John Porter wrote:
> 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 theore
Graham Barr wrote:
> 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 y
Philip Newton wrote:
> Having $seen{$word}++ turn $seen{$word} to undef is bad, if (undef)++
> assumes NULL semantics everywhere, hence "one more than unknown" = "still
> unknown".
Right. Applying NULL semantics to undef would be bad. The counterproposals to
RFC 263, along the lines of "use tr
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
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Replace XS with the C module as the standard way to extend Perl.
=head1 VERSION
Maintainer: Brian Ingerson <[EMAIL PROTECTED]>
Date: 21 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 270
Version
On Thu, 21 Sep 2000 15:37:36 -0400 (EDT), Andy Dougherty wrote:
>Still, even for me, I have never encountered a case where I wanted to
>maintain the same rand() sequence and also use a one-arg crypt().
>
>> I will add a note aboput this to the RFC. If there are no other
>> comments, I will freez
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Perl should not abort when a required file yields a false value
=head1 VERSION
Maintainer: Dominus <[EMAIL PROTECTED]>
Date: 21 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 269
Version: 1
St
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Keyed arrays
=head1 VERSION
Maintainer: Glenn Linderman <[EMAIL PROTECTED]>
Date: 20 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 268
Version: 1
Status: Developing
=head1 ABSTRACT
The ide
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
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:
my $x;
if (something)
{
$x = 1;
}
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
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
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
> "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
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.
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
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
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
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
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.
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
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
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
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'
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, 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 (
> =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
>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
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
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
> "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::
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.
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
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
=item perl6storm #0106
Safe "signals"! (not syssigs,really)
=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
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
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 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
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
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
>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 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
< 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 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])
> > 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 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
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
>Can't we all just play nice?
Apparently not. Several of us attempted to explain why this didn't
make sense, for many reasons. GL wouldn't hear any of it, stubbornly
adhering to this notion despite what was said, often completely
ignoring or apparently purposefully misunderstanding the points.
On Thu, 21 Sep 2000, Tom Christiansen wrote:
> A null is a null byte, or a null character. Period. You are
> completely out of your mind if you expect to co-opt an extant term
> for this screwed up notion of yours. I place my faith in Larry
> not to fuck up the language with your insanity.
>
Tom Christiansen wrote:
> A null is a null byte, or a null character. Period.
ASCII, a standard that long predates Perl, defines the term NUL, not NULL, to refer
to a null byte or null character. You are not correct, period or otherwise.
> You are
> completely out of your mind if you expect t
>> By your "reasoning", we can just add infinitely more things that
>> take twice a few pages to explain.
>You took that to an illogical extreme conclusion. Clearly you can't add
>everything to the language. However, it is clear by the set of currently
>submitted RFCs that more people think sug
>> In Perl, this is the null string:""
>> In Perl, this is the null character: "\0"
>> In Perl, this is the null list: ()
>In RFC 263, this is the null: null
>That's a different word for a different concept. No conflict, if you
>learn the way the RFC speaks.
Wrong. Just plain wrong.
>No, in that wonderfully consistent Perl documentation, it's "undef" not
>is only used to refer to (as you pointed out in another post)
> the null string
> the null character
> the null list
>Those use null as an adjective. This RFC proposes an addition to Perl t
> the null
>This use
On Wed, Sep 20, 2000 at 04:12:17AM -, Perl6 RFC Librarian wrote:
> Given this level of complexity, it's perhaps not surprising that source
> code filtering is not commonly used.
The both times I've attempted to use Filter::Util::Call, I've wound up
reverting to Filter::Util::Exec and doing so
On Thu, Sep 21, 2000 at 03:55:21AM -, Perl6 RFC Librarian wrote:
> Eliminate dump() function
I didn't even know it existed.
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
Any failu
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 hash keys can't be references is because
they're not really scalars. Internally th
CAPS LOCK KEY STUCK STOP
CANNOT PROGRAM PERL REVERTING TO BASIC STOP
SEND HELP QUICK STOP
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
When faced with desperate circumstances, we m
76 matches
Mail list logo
