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: Developing

=head1 ABSTRACT

Currently, Perl has the concept of C<undef>, which means that a value is
not defined. One thing it lacks, however, is the concept of C<null>,
which means that a value is known to be unknown or not applicable. These
are two separate concepts.

The absence of a C<null> concept and keyword in Perl makes it more
difficult to interface with relational databases and other medium which
utilize C<null>. Modules such as C<DBI> must map C<null> to C<undef>,
which is an imperfect match.

This RFC proposes a new C<null> keyword and fundamental value for Perl
6. 

=head1 DESCRIPTION

=head2 What is NULL anyways?

The concept of C<null> as opposed to C<undef> is sometimes difficult for
people to understand. Here is Glenn Linderman's great explanation,
directly from an email he posted to the list:

<quote>
There is a difference between "undefined" and "unknown".

SQL NULL, and the resultant tristate operators used in SQL, specifically
is based on NULL representing the "unknown" value.

Perl undefined is a different concept--that of an uninitialized
variable.  This is proven from its earliest versions where the value is
coerced to 0 or '' (specific values) when used (without warnings on).

Some Perl programs & modules (including DBI) attempt to correlate NULL
and undefined, for lack of a better match of concepts (Perl is missing
the concept of NULL, SQL is missing the concept of undefined, but that
doesn't correctly imply that the concepts each language _does_ have are
correlated, or should be).

If you want NULL, RFC it is a new concept.  DBI could then be ported to
Perl 6, and the power of using NULL in its operators (perhaps together
with transactional variables) could make Perl an extremely powerful
database manipulation language and would make the language,
complementary to and augmenting SQL in ways no other language currently
does.

Any OO language with full operator overloading could write
objects/operators that behave like SQL values, and implement tristate
logic for those objects, just like SQL does.  Perhaps you should attempt
that, and RFC the failures.  I would recommend, however, that you not
attempt to use the concept of undefined to implement the concept of
NULL, at least not visibly.
</quote>

=head2 Why the heck do we care?

As mentioned above, C<null> and <undef> are two different things
altogether. Consider the following two examples:

   undef                     null
   ------------------------  ------------------------
   $a = undef;               $a = null;
   $b = 1;                   $b = 1;
   $c = $a + b;              $c = $a + $b;

   $c is 1                   $c is null

The keyword C<null> means that a value is B<known to be unknown>. This
means a couple important things, with semantics far different from
C<undef>:

   1. Any math or string operation between a null and
      non-null value results in null

   2. No null value is equal to any other null, unlike
      undef

   3. A null value is neither defined nor undefined

To recap: There is no 1:1 mapping between C<undef> and <null>. Any
attempt to do so is inaccurate. For more details, please read the
references.

=head2 The new 'null' keyword

The new C<null> keyword can be used anywhere that C<undef> can be:

   my $name = null;
   null @array;
   @return = query($amount, $country, null, $time);
   die "Fatal, \$name was unset!" if ( $name == null );

With semantics to represent the RDBMS concept of C<null>. Note that the
last one works because we are simply testing against C<null>. However,
the following code:

   $a = null;
   $b = null;
   print '$a eq $b!' if ($a eq $b);

Would not print anything, since two C<null> values are not equivalent.

=head2 The 'initialize' pragma

The C<initialize> pragma is introduced to tell Perl what to default your
unitialized values to. By default, it will remain C<undef>, same as
currently. However, this code:

   use initialize 'null';   # or "use initialize 'undef'"

   my($a, $b);
   print "Hello world!" if ($a == $b);

Would no longer print out C<"Hello World!">, since the unitialized
values $a and $b would now be set to C<null>, rather than C<undef>. This
allows very easy porting of RDBMS-related work. The C<use initialize>
pragma should obey blocks as well:

   use initialize 'null';
   my($a, $b);
   print "Hello world!" if ($a == $b);
   {
       use initialize 'undef';
       my($c, $d);
       print "Hello universe!" if ($c == $d);

   }

The above example would print out "Hello universe!". By obeying blocks,
you can easily embed true SQL queries in your code without disrupting
the rest of the script.

=head1 IMPLEMENTATION

Add a C<null> keyword and fundamental value that have the proper
semantics.

Add an C<initialize> pragma that tells Perl what to initialize variables
to by default.

=head1 MIGRATION

None. New functionality.

=head1 REFERENCES

http://www.sitelite.nl/mysql/manual_Problems.html#IDX666

http://www.unb.ca/web/transpo/mynet/mtx19.htm#r2

Reply via email to