In message <2920001558$[EMAIL PROTECTED]>
Garrett Goebel <[EMAIL PROTECTED]> wrote:
> I'm particularly interested in commentary for and against:
> - the proposal as a whole
I think there's a big difference between the sort of short
circuiting provided by RFC 199 which I feel is bes
On Tue, Sep 19, 2000 at 10:11:23PM -0700, Nathan Wiger wrote:
>undef null
>
>$a = undef; $a = null;
>$b = 1; $b = 1;
>$c = $a + b; $c = $a + $b;
>
>$c is 1
On Wed, Sep 20, 2000 at 12:00:05AM -0700, Russ Allbery wrote:
> Perl already has exactly the data value that you're looking for. This RFC
> is proposing to fix the wrong problem; the things that need to be changed
> (conditionally) are the logical operators, not the data value.
Absolutley, altho
On Wed, Sep 20, 2000 at 05:08:26AM -, Perl6 RFC Librarian wrote:
> =head1 ABSTRACT
>
> This RFC proposes a built-in C function, modelled after Graham
> Barr's C subroutine from the List::Utils module (a.k.a. The
> Module Formerly Known As builtin.pm).
:-)
> If fewer than N-1 elements would
On 20 Sep 2000 04:12:09 -, Perl6 RFC Librarian <[EMAIL PROTECTED]> wrote:
> =head1 TITLE
>
> Add null() keyword and fundamental data type
>
> =head1 MIGRATION
>
> None. New functionality.
Not true. Apart from the discussion if undef is the same as null, in which I
take no stance, Migration
David Nicol Wrote in RFC 262:
>foreach $item (@items){
>#print "$item was at location ",$item:n,"\n";
>print "$item was at location ${item:n}\n";
>};
What would really be nice here is an C function, similar to the
scalar version, that returns the index of the matching entry in a list. For
instanc
On Wed, Sep 20, 2000 at 08:05:20AM -0400, Webmaster wrote:
> David Nicol Wrote in RFC 262:
> >foreach $item (@items){
> >#print "$item was at location ",$item:n,"\n";
> >print "$item was at location ${item:n}\n";
> >};
>
> What would really be nice here is an C function, similar to the
> scalar v
1. You don't say in your RFC, but I'm guessing, that a null value
evaluates to false in a boolean context. Correct?
2. In your abstract, you say that undef is used to mean that a
variable's value is undefined, which I presume means uninitialized.
You say that null would provide a useful way to i
Graham Barr Wrote:
>Well if there ever is a way to shortcut grep this could be genera;ized
>to
>
> my $index = grep { break if $_ eq $seek; 1 } @items;
Wouldn't this also assume that grep return the number of times the block was
NOT true, rather than it's current implementation of the number of
On Wed, Sep 20, 2000 at 09:03:39AM -0400, Webmaster wrote:
> Graham Barr Wrote:
> >Well if there ever is a way to shortcut grep this could be genera;ized
> >to
> >
> > my $index = grep { break if $_ eq $seek; 1 } @items;
>
> Wouldn't this also assume that grep return the number of times the bloc
> >undef null
> >
> >$a = undef; $a = null;
> >$b = 1; $b = 1;
> >$c = $a + b; $c = $a + $b;
> >
> >$c is 1 $c is null
I'm quite sure that
Graham Barr wrote:
>
> But what does it do if the block
> is a curried function of three arguments, but the list only contains two ?
Return a curried function of one argument, of course.
At least, that's what it *should* do...
--
John Porter
iain truskett wrote:
>
> Return a specified value (such as 'undef'). It would allow for more
> elegant code, I think. The universe is old enough to cope by itself.
When I first read this, I thought it said:
The universe is old enough to copy itself.
!-)
--
John Porter
Nathan Wiger wrote:
>
> Since undef() has established semantics, I don't think these should
> change. I believe taking from RDBMS and adding null() which has the
> correct NULL semantics is the way it should go.
You realize, I hope, that there is no end of different "special non-value"
semantics
Tom Christiansen wrote:
>
> You want to have more properties that work like tainting does: a
> per-SV attribute that is enabled or disabled by particular sorts
> of expressions, sometimes dependent upon the previous presence or
> absence of that property, other times, not so.
While we're at it,
Nathan Wiger wrote:
>
>undef null
>
>$a = undef; $a = null;
>$b = 1; $b = 1;
>$c = $a + b; $c = $a + $b;
>$c is 1 $c is null
Uh, this is a
On Tue, 19 Sep 2000, Tom Christiansen wrote:
> >This RFC proposes that the internal cursor iterated by the C function
> >be stored in the pad of the block containing the C, rather than
> >being stored within the hash being iterated.
>
> Then how do you specify which iterator is to be reset when
> If you want different semantics for undef then use a pragma, that is
> what pragmas are for.
> However I would suggest that many, including myself, would not like
> to see perls values have yet another state of null
Here's my concern about changing the meaning of undef. Convince me this
is not
On Wed, Sep 20, 2000 at 08:30:44AM -0700, Nathan Wiger wrote:
> Using the proposed tristate pragma does not strike me as any better -
> in fact, worse - than adding null() because you are now changing the
> meaning of fundamental Perl operations. You're *still* introducing "yet
> another state of
On Wed, Sep 20, 2000 at 08:30:44AM -0700, Nathan Wiger wrote:
> This is just as dangerous as having a pragma like so:
>
>use 'zeroistrue';
>$num = 0;
>print "Got data" if ( ! $num );
>
> Where the above would print out "Got data" normally, but not under
> the pragma.
Yep, this is ba
On Wed, Sep 20, 2000 at 04:12:09AM -, Perl6 RFC Librarian wrote:
> Add null() keyword and fundamental data type
I think that this is better done as a special overloaded object used
by database modules which wish to implement SQL-style tri-state logic.
Given that making overloaded objects fast
Graham Barr wrote:
>
> If you want an operator to act differently on some piece of data then a pragma
> is the way to do it.
I was thinking about this on the way to work. As much as I don't like
conflating undef and null, I dislike even more the idea of the 200 pages
in Learning Perl that will ha
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
>> Currently many programs handle error returns by examining the text of
>> the error returned in $@. This makes changes in the text of the error
>> message, an issue for the backwards compatibility police.
TC> eval { fn() };
TC>
On Wed, Sep 20, 2000 at 10:00:56AM -0700, Damien Neil wrote:
> On Wed, Sep 20, 2000 at 04:12:09AM -, Perl6 RFC Librarian wrote:
> > Add null() keyword and fundamental data type
>
> I think that this is better done as a special overloaded object used
> Incidentally, I'm surprised that DBI has
On Tue, Sep 19, 2000 at 08:05:50PM -0700, Nathan Wiger wrote:
> > $_ is not ALLCAPS. @EXPORT_OK should die (see RFC 233). @ISA is on
> > its way to its grave already, see C.
>
> Yeah, but you're still just sidestepping my point. Your position seems
> poised on the hope that no more special vari
Tom Christiansen wrote:
>
> >The warning for the use of an unassigned variable should be "use of
> >uninitialized variable C<$x>".
>
> The problem with that idea, now as before, is that this check happens
> where Perl is looking at a value, not a variable. Even were it possible
> to arduously m
Nathan Wiger wrote:
>
> Here's my concern about changing the meaning of undef.
>
> undef has a very well-defined (ha!) Perl meaning: that something is
> undefined.
Here's something you and Glenn don't seem to understand:
it doesn't *matter* what the human meaning of undef is.
Call it undefine
Nathan Wiger wrote:
>
> ...a "use tristate" pragma which obeys blocks
bka "lexically scoped". If I'm not mistaken, pragmas *are* lexically scoped.
--
John Porter
And what about $$x?
Dang, are we back to this incredible confusion about what it is to be
defined in Perl.?
undef $a;
That is now UNINITIALIZED. So is this:
$a = undef;
You have initialized it to undef. There is no reasonable difference.
Solution:
Remove all references from th
>Here's something you and Glenn don't seem to understand:
>it doesn't *matter* what the human meaning of undef is.
>Call it undefined, uninitialized, unknown, etc. etc.
>What matters is that in the perl machine, it's a different
>kind of value that a scalar can have, besides string, number,
>refer
>Nathan Wiger wrote:
>>
>> ...a "use tristate" pragma which obeys blocks
>bka "lexically scoped". If I'm not mistaken, pragmas *are* lexically scoped.
They *can* be. They needn't be.
--tom
Steve Fink wrote:
>I am merely suggesting that the compiler detect, when it can, that
>you're trying to use the value of a variable without ever having
>assigned a value to that variable. And in THAT message, you had better
>know the name of the variable, since it's the basis of the analysis. And
John Porter wrote:
> Nathan Wiger wrote:
> >
> >undef null
> >
> >$a = undef; $a = null;
> >$b = 1; $b = 1;
> >$c = $a + b; $c = $a + $b;
> >$c is 1
Damian Conway wrote:
>> > Should I point out that RFC 225 (Superpositions) actually covers
>> > most of this?
>> >
>> > C is equivalent in semantics to C or C.
> I hope you won't mind my pointing out that the documentation of the
> Quantum::Superpositions module -- to which the R
"Konovalov, Vadim" wrote:
> I'm quite sure that adding "null" into the language will complicate
> programming and hardly will give any benefits. One should differentiate
> between "null" and "undef", sometimes (or better always!) check variables
> with defined(...) *and* isnull(...).
Unlike unde
"H.Merijn Brand" wrote:
> On 20 Sep 2000 04:12:09 -, Perl6 RFC Librarian <[EMAIL PROTECTED]> wrote:
> > =head1 TITLE
> >
> > Add null() keyword and fundamental data type
> >
> > =head1 MIGRATION
> >
> > None. New functionality.
>
> Not true. Apart from the discussion if undef is the same as n
John Porter wrote:
> Nathan Wiger wrote:
> >
> > Since undef() has established semantics, I don't think these should
> > change. I believe taking from RDBMS and adding null() which has the
> > correct NULL semantics is the way it should go.
>
> You realize, I hope, that there is no end of differe
Russ Allbery wrote:
> Glenn Linderman <[EMAIL PROTECTED]> writes:
> > Russ Allbery wrote:
>
> >> I agree with Tom; I think it's pretty self-evident that they're the
> >> same thing. undef means exactly the same thing as null; that's not the
> >> problem. The problem is that Perl doesn't impleme
Sam Tregar wrote:
> On Tue, 19 Sep 2000, Glenn Linderman wrote:
>
> > They are different. Neither is a mistake.
>
> How do you explain the fact that every SQL book I've ever seen has
> included copious text on problems concerning NULL?
I'm not sure what SQL books you've seen. The standard trea
>The semantics for NULL is different, read the SQL standard.
Perl has no business contaminating itself with SQL.
--tom
Bad idea. See my multitudinous posts on why. Briefly:
1) can't use null and undef together
2) not extendable to 29 versions of null, when SQL defines them
Nathan Wiger wrote:
> Graham Barr wrote:
> >
> > If you want an operator to act differently on some piece of data then a pragma
> > is the
>Unlike undef, which gets assigned to uninitialized variables, NULL is only
>used by choice. So you only need deal with NULL when there is the
>possibility that it needs to be handled in some special way, and might exist
>as a value in the expression being handled.
This can be done without being
> no strict;
> $a = undef;
> $b = null;
Perl already has a null string: "".
--tom
Glenn Linderman wrote:
>Eric Roode wrote:
>
>> 1. You don't say in your RFC, but I'm guessing, that a null value
>> evaluates to false in a boolean context. Correct?
>
>I would expect it to be considered false. Logical expressions involving
>NULL are defined to be "undefined", actually, which is
* Tom Christiansen ([EMAIL PROTECTED]) [21 Sep 2000 05:49]:
> > no strict;
> > $a = undef;
> > $b = null;
> Perl already has a null string: "".
Looks more like a string of no length than a null string.
--
iain.
Damien Neil wrote:
> On Wed, Sep 20, 2000 at 04:12:09AM -, Perl6 RFC Librarian wrote:
> > Add null() keyword and fundamental data type
>
> I think that this is better done as a special overloaded object used
> by database modules which wish to implement SQL-style tri-state logic.
It could be
Perl has *one* out-of-band value. It doesn't need more. That
doesn't mean that perhaps some rare sorts of programming might not
benefit from fancy weirdnesses. That's what modules are for.
You don't need to complicate the general language to get what
you want. Don't make others pay for your pr
>$a = null;
>$b = ($a == 42);
>print defined($b)? "defined" : "not defined";
>would print "not defined", maybe?
In a sane world of real (non-oo-sneaky) perl, the "==" operator returns
only 1 or "". Both are defined.
--tom
>It only takes a few pages, and a few truth tables to explain NULL.
>It should only take a few pages and a few examples, to explain the
>difference between undef and null.
Ah, so the cost of this is twice a few pages of explanation, plus truth
tables and examples? Are you mad?
I can think of n
>* Tom Christiansen ([EMAIL PROTECTED]) [21 Sep 2000 05:49]:
>> > no strict;
>> > $a = undef;
>> > $b = null;
>> Perl already has a null string: "".
>Looks more like a string of no length than a null string.
Well, it's not. That's a null string. You're thinking of "\0",
a true va
>> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
>>> Currently many programs handle error returns by examining the text of
>>> the error returned in $@. This makes changes in the text of the error
>>> message, an issue for the backwards compatibility police.
>TC> eval { fn() };
>
Today around 1:03pm, Tom Christiansen hammered out this masterpiece:
: Perl has *one* out-of-band value. It doesn't need more. That
: doesn't mean that perhaps some rare sorts of programming might not
: benefit from fancy weirdnesses. That's what modules are for.
: You don't need to complicate
* Tom Christiansen ([EMAIL PROTECTED]) [21 Sep 2000 06:09]:
> iain wrote:
> > * Tom Christiansen ([EMAIL PROTECTED]) [21 Sep 2000 05:49]:
> > > > no strict;
> > > > $a = undef;
> > > > $b = null;
> > > Perl already has a null string: "".
> > Looks more like a string of no length than
Eric Roode wrote:
> Glenn Linderman wrote:
> >Eric Roode wrote:
> >
> >> 1. You don't say in your RFC, but I'm guessing, that a null value
> >> evaluates to false in a boolean context. Correct?
> >
> >I would expect it to be considered false. Logical expressions involving
> >NULL are defined to
Tom Christiansen wrote:
> > no strict;
> > $a = undef;
> > $b = null;
>
> Perl already has a null string: "".
That's an empty string. In any case, if you really want to call it a
null string, that's fine, just a little more likely to be
misinterpreted. NULL is neither number nor st
Tom Christiansen wrote:
> Perl has *one* out-of-band value. It doesn't need more. That
> doesn't mean that perhaps some rare sorts of programming might not
> benefit from fancy weirdnesses. That's what modules are for.
> You don't need to complicate the general language to get what
> you want.
That's not much different than the cost of undef, so I fear it proves
nothing, universally.
Tom Christiansen wrote:
> >It only takes a few pages, and a few truth tables to explain NULL.
> >It should only take a few pages and a few examples, to explain the
> >difference between undef and null.
>
> Some of oriental characters in Japanese and Korean are usually
> aligned as if they have 2 columns per character.
>
> Japanese has another formatting rule that punctuation characters
> cannot appear at the beginning of or end of line (depending on
> their meanings).
The pro
Nathan Wiger <[EMAIL PROTECTED]> writes:
> undef has a very well-defined (ha!) Perl meaning: that something is
> undefined. null has a very well-defined RDBMS meaning: that something is
> unknown. Perl allows you to add and concatenate stuff to undef, because
> that value can be coerced into 0 an
Jonathan Scott Duff <[EMAIL PROTECTED]> writes:
> Yep, this is bad IMHO. Your concern is valid I think, but your
> "solution" isn't a good one. Why not just use a module like Damian's
> Quantum::Superpositions?
No offense to Damian, but I tried to read and understand his documentation
and I th
Glenn Linderman <[EMAIL PROTECTED]> writes:
> With the multitudinous operator approach, please show me how to make
> each of the following conditional statements print true, without
> cluttering the code with interleaved additional pragmas and scoping
> blocks. Use of pragmas before the code mig
Glenn Linderman <[EMAIL PROTECTED]> writes:
> undef has the following semantics:
> 1) all otherwise uninitialized variables are set to undef
And as the RFC says, quite a few times, for database code you often want
all your variables to start as the null value.
> 2) under "use strict", use of u
Tom Christiansen <[EMAIL PROTECTED]> writes:
>>$a = null;
>>$b = ($a == 42);
>>print defined($b)? "defined" : "not defined";
>> would print "not defined", maybe?
> In a sane world of real (non-oo-sneaky) perl, the "==" operator returns
> only 1 or "". Both are defined.
But if you
>That's not much different than the cost of undef, so I fear it proves
>nothing, universally.
YOU OVERQUOTEDsen wrote:
YOU OVERQUOTEDkes a few pages, and a few truth tables to explain NULL.
YOU OVERQUOTEDonly take a few pages and a few examples, to explain the
YOU OVERQUOTED between undef and nu
>> For example, assuming this code:
>>$name = undef;
>>print "Hello world!" if ($name eq undef);
>So don't do that. Use C if you want to ask that question.
That's why I want to change the names of these things. The current
situation invites errors such as seen previously.
Actually,
>Tom Christiansen wrote:
>> > no strict;
>> > $a = undef;
>> > $b = null;
>>
>> Perl already has a null string: "".
>That's an empty string. In any case, if you really want to call it a
>null string, that's fine, just a little more likely to be
>misinterpreted.
In Perl, this is t
>> I'm not happy with your use of "coerce". There's no mutation. It simply
>> *is* those things.
>Fine. So, in particular, it _isn't_ null.
Of course it's null. That's why it has length zero. Stop speaking
SQL at me. I'm speaking Perl.
>> 4) The antiïinitialized value is autovivified to a
Tom Christiansen wrote:
>
> By your "reasoning", we can just add infinitely more things that
> take twice a few pages to explain.
>
> Perl is already too hard.
Yes, it is.
And that's why I'm against C.
(Had to get that plug in there) ;-)
-Nate
* Russ Allbery ([EMAIL PROTECTED]) [21 Sep 2000 07:22]:
> Jonathan Scott Duff <[EMAIL PROTECTED]> writes:
> > Yep, this is bad IMHO. Your concern is valid I think, but your
> > "solution" isn't a good one. Why not just use a module like
> > Damian's Quantum::Superpositions?
> No offense to Dam
On Wed, Sep 20, 2000 at 07:45:16PM -, Perl6 RFC Librarian wrote:
> "VARIABLE used only once: possible typo" should be replaced with
> warnings on uses of uninitialized variables (including lexicals).
> $x = 3
I don't understand, who's to say you didn't misspell $x? If you're only
using it
On Wed, Sep 20, 2000 at 11:58:08AM -0700, Glenn Linderman wrote:
> > I think that this is better done as a special overloaded object used
> > by database modules which wish to implement SQL-style tri-state logic.
>
> It could be done as an overloaded object. You'd have to be able to overload all
Glenn Linderman wrote:
> Not a solution.
Frankly, you haven't demonstrated that there's a problem.
--
John Porter
In message <[EMAIL PROTECTED]>
Dave Storrs <[EMAIL PROTECTED]> wrote:
> This runs into problems if you currently have an iterator extant and you
> modify the hash to which it points. Immediate suggestions on how to
> handle this would be:
>
> 1) Do what the docs currently do; tel
On Wed, Sep 20, 2000 at 01:21:52PM -0700, Russ Allbery wrote:
> No offense to Damian, but I tried to read and understand his documentation
> and I thought I was back in grad school. I don't think it's the fault of
> the writing either; I think that Quantum::Superpositions is trying to do
> someth
On Wed, Sep 20, 2000 at 02:47:01PM -0600, Tom Christiansen wrote:
> In Perl, this is the null character: "\0"
...
> It's a shame you don't like it, but this is the way we speak.
Well, it's the way you speak. Myself, I'd call that the NUL
character. :>
- Damien, exercising a pet pe
On Fri, 15 Sep 2000 10:29:31 +1100 (EST), Damian Conway wrote:
>Why not just give \I..\E a special "turn-on-interpolation" meaning in
>q{} docs?
This has been uppered already in the pre-discussion to this RFC.
Currently, '\I' is nothing special in q{}, and a lot of people don't
want to chage tha
> >$a = null;
> >$b = ($a == 42);
> >print defined($b)? "defined" : "not defined";
>
> >would print "not defined", maybe?
defined() is the wrong operator to be using there. Rather,
$a = null;
$b = ($a == 42);
print is_null($b)? "is null" : "is not null";
In general,
At 12:38 PM 9/20/00 -0700, Glenn Linderman wrote:
>OK, scalar variables. But I see code in the XML modules that check
>defined (@array)
Then they should be fixed. That doesn't do anything useful right now.
>Interesting. I learn something every day. Today, you helped. Maybe you
>can help
>
Damien Neil <[EMAIL PROTECTED]> writes:
> If I could be assured that the performance penalty was minimal, I'd
> be delighted to write
> if ($errno == any(EAGAIN EINTR)) { ... }
> over
> if ($errno == EAGAIN || $errno == EINTR) { ... }
> The former is less typing and reads more clearly (to
Eric Roode wrote:
>
> Steve Fink wrote:
> >I am merely suggesting that the compiler detect, when it can, that
> >you're trying to use the value of a variable without ever having
> >assigned a value to that variable. And in THAT message, you had better
> >know the name of the variable, since it's
>But that doesn't even matter that much here; I'm saying that if the
>compiler can definitely determine that you are using an uninitialized
>variable, it should warn.
...
>$x is a global. The compiler cannot detect all possible assignments to
>or accesses of globals, so it never warns about the
Michael Fowler wrote:
>
> On Wed, Sep 20, 2000 at 07:45:16PM -, Perl6 RFC Librarian wrote:
> > "VARIABLE used only once: possible typo" should be replaced with
> > warnings on uses of uninitialized variables (including lexicals).
>
> > $x = 3
>
> I don't understand, who's to say you didn't
Tom Christiansen wrote:
>
> And what about $$x?
>
> Dang, are we back to this incredible confusion about what it is to be
> defined in Perl.?
>
> undef $a;
>
> That is now UNINITIALIZED. So is this:
>
> $a = undef;
>
> You have initialized it to undef. There is no reasonable differ
On Wed, Sep 20, 2000 at 03:25:11PM -0700, Steve Fink wrote:
> > > complains, but
> > >
> > > $x = 3; $x = 3
> >
> > As it shouldn't; you've mentioned $x twice, which means you probably didn't
> > misspell it. That your mentioning twice in this manner is silly is beyond
> > perl's grasp.
>
> Ac
>Which is silly, because you shouldn't have to say '$x = $x = 3' when you
>mean '$x = 3'. Just because there's a real reason behind it doesn't make it
>any less silly.
I'd like to see where this can happen. Sounds like someone forgot to
declare something:
our $x;
$x = 2;
--tom
>Anything else? Any opinion on whether eval "" should do what it does
>now, and be invisible for the purposes of this analysis; or if it should
>be assumed to instead both use and initialize all visible variables? The
>former produces more spurious warnings, the latter misses many errors.
You hav
Tom Christiansen wrote:
>
> >Same thing. If $x is lexical, it gives a definite warning. If $x is a
> >global, it says nothing. You're right; I need to point this out in the
> >RFC.
>
> Careful:
>
> sub ouch {
> my $x;
> my $fn = sub { $x++ };
> register($fn);
>
On Wed, Sep 20, 2000 at 05:10:55PM -0600, Tom Christiansen wrote:
> >Which is silly, because you shouldn't have to say '$x = $x = 3' when you
> >mean '$x = 3'. Just because there's a real reason behind it doesn't make it
> >any less silly.
>
> I'd like to see where this can happen. Sounds like
> >Which is silly, because you shouldn't have to say '$x = $x = 3' when you
> >mean '$x = 3'. Just because there's a real reason behind it doesn't make it
> >any less silly.
>
> I'd like to see where this can happen. Sounds like someone forgot to
> declare something:
>
> our $x;
> $x =
>It happens when I don't bother to declare something. My company has
>several dozen machines with an 'our'-less perl, and 'use vars qw($x)' is
>a pain. As is $My::Package::Name::x.
Far, far easier to fix behavioral problems than to hack Perl.
--tom
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
TC> I'm saying that you can't know what to check for, because you don't
TC> know who generated the exception. Can you use your fancy constants?
Then please tell me how anyone has ever coded
$@ =~ //
They don't know what to
Ok, so you want message catalogues, and not solely on Perl but anything
in the distribution. You should say that.
--tom
Michael Fowler wrote:
>
> On Wed, Sep 20, 2000 at 03:25:11PM -0700, Steve Fink wrote:
> > > > complains, but
> > > >
> > > > $x = 3; $x = 3
> > >
> > > As it shouldn't; you've mentioned $x twice, which means you probably didn't
> > > misspell it. That your mentioning twice in this manner is sil
All this talk about adding another undef, called null, that is just a
different logical and semantical version of "not defined," or "not
known," or however you want to say it, strikes me as very odd.
I admit I am new enough to Perl that 5 was my first version, but still...
it seems better to make
Tom Christiansen wrote:
>
> >It happens when I don't bother to declare something. My company has
> >several dozen machines with an 'our'-less perl, and 'use vars qw($x)' is
> >a pain. As is $My::Package::Name::x.
>
> Far, far easier to fix behavioral problems than to hack Perl.
>
> --tom
Not s
Tom Christiansen wrote:
>
> >Anything else? Any opinion on whether eval "" should do what it does
> >now, and be invisible for the purposes of this analysis; or if it should
> >be assumed to instead both use and initialize all visible variables? The
> >former produces more spurious warnings, the
On Wed, Sep 20, 2000 at 05:20:54PM -0700, Steve Fink wrote:
> > $foobal = 3;
> > if (@ARGV) {
> > $foobar = @ARGV;
> > }
> >
> > print $foobar;
> >
> > Only warn me that $foobar is uninitialized? I always prefer it when the
> > actual source of my problem is pointed out,
At 03:37 PM 9/17/00 -0700, I wrote:
> How about an attribute for hashes:
>
> my %foo : fixed;
>
>And now new keys cannot be inserted into the hash just by assigning to
>their values. As to how you could put them there... well the ideas that
>come to mind are [snipped]
>
Spurred on by t
Michael Fowler wrote:
>
> On Wed, Sep 20, 2000 at 05:20:54PM -0700, Steve Fink wrote:
> > > $foobal = 3;
> > > if (@ARGV) {
> > > $foobar = @ARGV;
> > > }
> > >
> > > print $foobar;
> > >
> > > Only warn me that $foobar is uninitialized? I always prefer it when the
> > >
>Tom Christiansen wrote:
>>
>> >Anything else? Any opinion on whether eval "" should do what it does
>> >now, and be invisible for the purposes of this analysis; or if it should
>> >be assumed to instead both use and initialize all visible variables? The
>> >former produces more spurious warnings
1 - 100 of 127 matches
Mail list logo
