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 Lar
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
On Wed, Sep 20, 2000 at 04:12:09AM -, Perl6 RFC Librarian wrote:
> The concept of C as opposed to C 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 who ought
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 i
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 us
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
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:
>
> > 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 ar
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
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
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
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?
> >
> >
>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
< 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
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
>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
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 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
>But I see code in the XML modules that check defined (@array)
They're buggy and wrong.
--tom
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
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 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
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
* 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
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
>* 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
"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
>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
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:
>
> 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
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
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
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
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 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
> 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
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
> >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
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
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
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 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
> > Should I point out that RFC 225 (Superpositions) actually covers
> > most of this?
> >
> > C is equivalent in semantics to C or C.
>
> 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,
>
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 semant
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. Neithe
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'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 spend my time
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
Sam Tregar wrote:
> Does it really make it more difficult? I would argue that having NULLs
> mapped to undefs is actually better than having real NULLs in Perl. An
> undef is a rather concrete and easily dealt with value - simply test with
> defined(). Plus, if you're careless enough to try to
Glenn Linderman <[EMAIL PROTECTED]> writes:
> Tom Christiansen wrote:
>>> Currently, Perl has the concept of C, which means that a value
>>> is not defined. One thing it lacks, however, is the concept of
>>> C, which means that a value is known to be unknown or not
>>> applicable. These are two s
Tom Christiansen wrote:
> >Currently, Perl has the concept of C, which means that a value is
> >not defined. One thing it lacks, however, is the concept of C,
> >which means that a value is known to be unknown or not applicable. These
> >are two separate concepts.
>
> No, they aren't.
>
> --tom
At 10:11 PM 9/19/00 -0700, Nathan Wiger wrote:
>Tom Christiansen wrote:
> >
> > >Currently, Perl has the concept of C, which means that a value is
> > >not defined. One thing it lacks, however, is the concept of C,
> > >which means that a value is known to be unknown or not applicable. These
> > >
On 20 Sep 2000, Perl6 RFC Librarian wrote:
> The absence of a C concept and keyword in Perl makes it more
> difficult to interface with relational databases and other medium which
> utilize C. Modules such as C must map C to C,
> which is an imperfect match.
Does it really make it more difficult
Tom Christiansen wrote:
>
> >Currently, Perl has the concept of C, which means that a value is
> >not defined. One thing it lacks, however, is the concept of C,
> >which means that a value is known to be unknown or not applicable. These
> >are two separate concepts.
>
> No, they aren't.
Uhhh, y
>Currently, Perl has the concept of C, which means that a value is
>not defined. One thing it lacks, however, is the concept of C,
>which means that a value is known to be unknown or not applicable. These
>are two separate concepts.
No, they aren't.
--tom
Should I point out that RFC 225 (Superpositions) actually covers most of this?
C is equivalent in semantics to C or C.
Except, of course, the superpositional versions work...In Constant Time!
;-)
Damian
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: De
97 matches
Mail list logo
