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 tri-state
> >> logic semantics that most users of null are used to, which is a
> >> different issue.
>
> > So, to paraphrase your statement a bit:
>
> > It is self-evident that they're the same, the problem is that they work
> > differently.
>
> No, that's not a paraphrase. That's saying something completely different
> which is wrong.
I still find it a paraphrase... discussion below.
> If undef functioned differently than null, that would be a bug.
False statement. undef has the following semantics:
1) all otherwise uninitialized variables are set to undef
2) under "use strict", use of undef in expressions is diagnosed with a warning
3) undef is coerced to 0 in numeric expressions, false in boolean expressions,
and the empty string in string expressions.
The semantics for NULL is different, read the SQL standard. The _definitions_
of undef and NULL are different; if they functioned the same, that would be a
bug.
> What's
> missing is a way to say "I want tri-state logic" as a pragma. When that
> pragma is enabled, undef would be the null-like state.
This could be done, but then you could only use either the concept of undef
(as defined by perl and recapped above), or the semantics of NULL, but not
both.
Another person has suggested privately that rather than a pragma, that
different operators could be provided for all operations, which apply the NULL
functional semantics to their arguments. This could also be done, but would
require the programmer to choose the desired semantics for every operation, by
choosing the appropriate operator. It would also double the number of
operators in the language. Not nice.
> 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.
Nope, the data value Perl has has different operational semantics that the
data value this RFC is suggesting.
> > Nota Bene: IEEE floating point defines two different concepts that are
> > not numbers, but can be mixed with numbers in expressions: Inf and NaN.
> > And actually, there are positive and negative varieties of both Inf and
> > NaN. So I guess you might say that they are the same; but the problem
> > is that they work differently.
>
> There are positive and negative infinities, but that's a different
> situation entirely; infinity is a degenerate value, not an undefined
> value. This is the first time I've ever heard of -NaN; are you sure about
> that? (There are, in fact, different types of NaN, such as signalling vs.
> non-signalling, but that's due to floating point traps and exceptions,
> issues that don't crop up in the situations where you want undef/null.)
Sorry, the intended point was that IEEE float has (1) multiple types of
distinguished, non-numeric values with different semantics and (2) for each
type of distinguished, non-numeric value it has, multiple values of that type
exist.
However, there are legal forms of NaN with the sign bit set, and legal forms
of NaN with the sign bit reset. They are not called positive and negative,
however, that was an oversimplification.
--
Glenn
=====
Even if you're on the right track,
you'll get run over if you just sit there.
-- Will Rogers
_____NetZero Free Internet Access and Email______
http://www.netzero.net/download/index.html
