This is screaming mad. I will become perl6's greatest detractor and
anti-campaigner if this nullcrap happens. And I will never shut up
about it,
either. Mark my words.
Visit our website at http://www.ubswarburg.com
This message contains confidential information and is intended only
for the
On Wed, Sep 20, 2000 at 04:12:09AM -, Perl6 RFC Librarian wrote:
The concept of Cnull as opposed to Cundef is sometimes difficult for
people to understand.
"People" in this context being the people who are reading perl6-language and
purporting to be able to know what Perl 6 needs. People
On Wednesday, September 27, 2000 4:17 AM, Tom Christiansen
[SMTP:[EMAIL PROTECTED]] wrote:
This is screaming mad. I will become perl6's greatest detractor and
anti-campaigner if this nullcrap happens. And I will never shut up
about it,
either. Mark my words.
Quote from Larry: "I have a
David Grove wrote:
On Wednesday, September 27, 2000 4:17 AM, Tom Christiansen wrote:
This is screaming mad. I will become perl6's greatest detractor and
anti-campaigner if this nullcrap happens. And I will never shut up
about it,
either. Mark my words.
Quote from Larry: "I have
At 10:26 AM 9/27/00 +0100, Simon Cozens wrote:
On Wed, Sep 20, 2000 at 04:12:09AM -, Perl6 RFC Librarian wrote:
The concept of Cnull as opposed to Cundef is sometimes difficult for
people to understand.
"People" in this context being the people who are reading perl6-language and
Glenn Linderman [EMAIL PROTECTED] writes:
Russ Allbery wrote:
Perhaps I don't use those warnings in the same way that you do. I
*very* rarely have undefined value warnings in my programs, and when I
do they're usually not actually bugs, just things that require a
different way of writing
Russ Allbery wrote:
use 'strict' is probably the difference between our code... I tend not to use
it, because I wrote a bunch of code that didn't, initially, before I heard of
it (maybe before it existed? I started with Perl 4.something), and haven't
gotten it all converted so that it can be
On Fri, 22 Sep 2000, Glenn Linderman wrote:
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. This comment assumes that the
current undef is
Glenn Linderman said [in response to Russ]:
...maybe explaining the types of confusion that you see
with a separate null and undef vs the types of confusion that you see with a
tristate pragma would help me to grasp that logic.
I don't see why we need to keep spinning our wheels on this
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.
The RFC
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
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: ()
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 wonderfully
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 warning
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
NULL). To quote
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 conform
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 print a
No, in that wonderfully consistent Perl documentation, it's "undef" not SNIP
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 tSNIP
the null
This
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.
It's
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
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 to
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.
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's
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
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 explicitly
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 implement
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.
--tom
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 by
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
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
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?
Apparently
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
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 you are not
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 theoretical
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 in
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
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
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 either
Damian Conway wrote:
Should I point out that RFC 225 (Superpositions) actually covers most of this?
Cnull is equivalent in semantics to Cany() or Call().
I'd love to read your not yet available paper to which the RFC refers. However,
until it is available, and I have time to read it, I'll
On Tue, 19 Sep 2000, Glenn Linderman wrote:
I agree that undef and NULL have different semantics. However, this is
clearly SQL's fault and not Perl's. We shouldn't repeat their mistake
just because we occasionally have to interface with their system.
They are different. Neither is a
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 implement the tri-state
logic semantics that
Should I point out that RFC 225 (Superpositions) actually covers
most of this?
Cnull is equivalent in semantics to Cany() or Call().
I'd love to read your not yet available paper to which the RFC
refers. However, until it is available, and I have time to read it,
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,
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 *is* an
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
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 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 have
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 hasn't
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 undefined,
Nathan Wiger wrote:
...a "use tristate" pragma which obeys blocks
bka "lexically scoped". If I'm not mistaken, pragmas *are* lexically scoped.
--
John Porter
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
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 $c is
Damian Conway wrote:
Should I point out that RFC 225 (Superpositions) actually covers
most of this?
Cnull is equivalent in semantics to Cany() or Call().
I hope you won't mind my pointing out that the documentation of the
Quantum::Superpositions module -- to which the
"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 undef,
"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 null, in which I
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 implement the
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 treatise
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 way
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 in
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 not
* 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 done
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
$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 no
* 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 value in Perl.
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
* 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 a null string.
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 be "undefined",
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 string,
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.
Ah,
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 and ""
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
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
For example, assuming this code:
$name = undef;
print "Hello world!" if ($name eq undef);
So don't do that. Use Cdefined $name 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.
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 the null string:
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 true
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 Cuse invocant.
(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 Damian, but
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
the
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
something
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
$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, what
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
some
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 me, at
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
But I see code in the XML modules that check defined (@array)
They're buggy and wrong.
--tom
Should I point out that RFC 225 (Superpositions) actually covers most of this?
Cnull is equivalent in semantics to Cany() or Call().
Except, of course, the superpositional versions work...In Constant Time!
;-)
Damian
Tom Christiansen wrote:
Currently, Perl has the concept of Cundef, which means that a value is
not defined. One thing it lacks, however, is the concept of Cnull,
which means that a value is known to be unknown or not applicable. These
are two separate concepts.
No, they aren't.
Uhhh,
On 20 Sep 2000, Perl6 RFC Librarian wrote:
The absence of a Cnull concept and keyword in Perl makes it more
difficult to interface with relational databases and other medium which
utilize Cnull. Modules such as CDBI must map Cnull to Cundef,
which is an imperfect match.
Does it really make
At 10:11 PM 9/19/00 -0700, Nathan Wiger wrote:
Tom Christiansen wrote:
Currently, Perl has the concept of Cundef, which means that a value is
not defined. One thing it lacks, however, is the concept of Cnull,
which means that a value is known to be unknown or not applicable. These
are
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Add null() keyword and fundamental data type
=head1 VERSION
Maintainer: Nathan Wiger [EMAIL PROTECTED]
Date: 19 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 263
Version: 1
Status:
Currently, Perl has the concept of Cundef, which means that a value is
not defined. One thing it lacks, however, is the concept of Cnull,
which means that a value is known to be unknown or not applicable. These
are two separate concepts.
No, they aren't.
--tom
98 matches
Mail list logo
