Damien Neil wrote:
> I suggest that you read up on the difference between "use strrict" and
> "use warnings"/-w.
Thanks, yes, I figured out the "no warnings" issue afterwards.
> Furthermore, you may wish to take the five seconds necessary to
> understand WHY it prints that message when you prin
Peter Scott wrote:
> $employee{$empno}{SAlARY} -= 10_000; # IPO failure
> $employee{$empno}{FAX} = '888-555-1212';
>
> First one got the wrong key when my finger slipped on the shift key, second
> one got it when I misremembered FAX instead of FACSIMILE. But in neither
>
Paris Sinclair wrote:
> If
> you need additional semantics than provided by undef, why not make a
> module?
This might be workable. There are some thoughts on that. Personally, I
haven't used that much overloading in Perl to know whether it can be made to
work well enough to completely confor
John Porter wrote:
> > >$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,
The tri-state logic deals with "true", "false", and "unknown" (not
NUL
Peter Scott wrote:
> 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.
I tried to fix it according to the suggested fix in the war
Tom Christiansen wrote:
> >> 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.
No, in that wond
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.
> I don't believe you actually need both semantics active at the same time;
I do. Need might be a slightly stronge
Tom Christiansen wrote:
> >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 the null string:""
> In Perl, this is the null character: "\0"
> In Perl, this is the null list
> 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 suggesti
Russ Allbery wrote:
> 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.
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Eliminate dump() function
=head1 VERSION
Maintainer: Dominus <[EMAIL PROTECTED]>
Date: 20 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 267
Version: 1
Status: Developing
=head1 ABSTRACT
Get
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Any scalar can be a hash key
=head1 VERSION
Maintainer: Steve Fink <[EMAIL PROTECTED]>
Date: 20 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 266
Version: 1
Status: Developing
=head1 ABSTRAC
I don't have time to RFC this now, as I'm leaving soon for several days.
So here's a brain dump.
Camel-3 shows some interesting hints of what's been proposed for my
declarations:
my type $var :attribute = $value;
And we all know that you can use my to declare a group of variables:
my($x,
Ok, at this point I'm trying to clear up misunderstandings. I believe you
know where I stand with relation to your RFC.
On Wed, Sep 20, 2000 at 06:41:52PM -0700, Steve Fink wrote:
> Michael Fowler wrote:
> > Except for the line number reported, which is the important part.
>
> Oh. Certainly yo
On Wed, Sep 20, 2000 at 07:20:44PM -0700, Steve Fink wrote:
> Tom Christiansen wrote:
> > Steve Fink wrote:
> > >% perl -we '$x = 3; $v = "x"; eval "\$$v++"'
> > >Name "main::x" used only once: possible typo at -e line 1.
> >
> > Non sequitur. And no, I don't have time.
>
> It is relevant in that
Have a nice day. And thanks for all the fish.
Tom Christiansen wrote:
>
> >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
> >> >
Tom Christiansen wrote:
>
> >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
>But I see code in the XML modules that check defined (@array)
They're buggy and wrong.
--tom
>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.
>>
>> --t
>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
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
> > >
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
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,
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
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
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
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
Ok, so you want message catalogues, and not solely on Perl but anything
in the distribution. You should say that.
--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
>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
> >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 =
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
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Replace C built-in with C function
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 15 Sep 2000
Last Modified: 20 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 230
Version:
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);
>
>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
>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
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
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
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
>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
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
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
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
>
> >$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,
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
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 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
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
Glenn Linderman wrote:
> Not a solution.
Frankly, you haven't demonstrated that there's a problem.
--
John Porter
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
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
* 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
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
>> 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:
>> > 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
>> 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,
>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
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
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
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
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
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
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Builtins : Make use of hashref context for garrulous builtins
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 19 Sep 2000
Last Updated: 20 Sep 2000
Mailing List: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Built-in functions should be functions
=head1 VERSION
Maintainer: Johan Vromans <[EMAIL PROTECTED]>
Date: 27 Aug 2000
Last Modified: 20 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 168
Versi
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
linkable output mode
=head1 VERSION
Maintainer: David Nicol <[EMAIL PROTECTED]>
Date: 17 Aug 2000
Last Modified: 20 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 121
Version: 2
Status: Fro
> 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
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Builtin: reduce
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 10 August 2000
Last Modified: 20 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 76
Version: 4
Status: Froze
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
variable usage warnings
=head1 VERSION
Maintainer: Steve Fink <[EMAIL PROTECTED]>
Date: 2 Aug 2000
Last Modified: 20 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 12
Version: 3
Status: Deve
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.
>
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.
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
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 ([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
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
>> "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() };
>
Perl6 RFC Librarian wrote:
[...]
> =head1 TITLE
>
> All perl generated errors should have a unique identifier
>
[...]
> An id string could have some structure associated to enable
> better handling. One suggestion was to follow the lead of VMS.
>
> facility:
> The program
>* 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
>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
>$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
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
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
* 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.
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
> no strict;
> $a = undef;
> $b = null;
Perl already has a null string: "".
--tom
>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
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
>The semantics for NULL is different, read the SQL standard.
Perl has no business contaminating itself with SQL.
--tom
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
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
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
"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
"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
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
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
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
>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
>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
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
Nathan Wiger wrote:
>
> ...a "use tristate" pragma which obeys blocks
bka "lexically scoped". If I'm not mistaken, pragmas *are* lexically scoped.
--
John Porter
1 - 100 of 127 matches
Mail list logo
