From: Ben Bullock on
Ted <r.ted.byers(a)rogers.com> wrote:

>> Try running the following script to clarify what this means:
>>
>> #!/usr/bin/perl
>> use warnings;
>> use strict;
>> my $a;
>> my $b = "";
>> print "a is defined\n" if defined($a);
>> print "b is defined\n" if defined($b);
>>
>> Here $b is a "real null string" and $a is undefined.

Excuse me, this should say '$b is a "defined null string"' not "real".

> No. $b holds an empty string, and empty strings are not the same thing
> as NULL (as defined in either C++ and Java or SQL).

But I'm not talking about C++ or Java or SQL. I'm talking about
Perl. This is a perl newsgroup. "" is what the book you're referring
to means by a "defined null string", as opposed to an undefined value.

> But that is exactly what Wall et al. said about undefined. I learned
> much of what I know about Perl from their book, and they said that an
> undefined variable is one that does not have a valid string, number or
> reference, and that exactly describes a variable that has not yet been
> initialized. The empty string is a valid string in all of the
> languages I use, and it means something quite different from a SQL
> null.

We're not talking about the empty string any more, the above is
talking about an undefined value. As I pointed out in the two scripts,
$b="" and $b=undef are two totally different things.

>> > But ALL of these concepts are very different from the idea of NULL in
>> > SQL. �For example, The book, from Osborne, "SQL: The complete reference"
>> > by James Groff and Paul Weinberg, described it as referring to data that
>> > is missing, unknown, or don't apply.
>>
>> Which seems to be exactly what the undefined value in Perl is, to me.
>>
> Then you're using a definition of the term that is quite different
> from what Wall et al. wrote about undefined. Where they wrong, or
> merely misleading?

Look at this kind of example:

my @arr = (undef, 1, 3, undef, 4);

If you then refer to $arr[3] you get the undefined value. So you can
assign it into a variable. What is more you can do things like

(undef, $x, $y) = @z;

to ignore the value of $z[0].

I don't know how that compares to SQL's NULL in detail, but it seems
to me that this refers to data that is "missing, unknown or does not
apply", thus from your statement this "seems to be exactly what the
undefined value in Perl is, to me", as I said.

>> > While NULL in SQL is different from
>> > numeric or string data, I see nothing in the idea that indicates it is a
>> > value that is not part of the normal range of values.
>>
>> Perhaps you can think of Perl's undef as being part of the normal range
>> of values, too.
>>
> In principal I'd have no problem with that, if it weren't for the fact
> that Wall et al. described them as referring to variables that were
> not initialized.

You keep on and on repeating this but I've already pointed out to you
that it doesn't mean that. Did you actually try running or even
reading those scripts I gave? You need to spend a lot more time
reading and writing Perl code and a lot less time in creating mounds
of verbiage.

>> > I see nothing similar between the idea of NULL in SQL and either null or
>> > undefined in the other languages.
>>
>> That's odd, because the more you talk about SQL's NULL, the more it looks
>> like Perl's undefined value to me.
>>
> Until now, I had seen nothing written about perl that suggested that
> Wall et al.'s description of undefined meant anything other than a
> reference to variables that had not yet been initialized, and that is
> a very different concept from SQL's NULL.

Please don't say "not yet" again, I've already given you counter
examples for that.

> Why would you object to my leveraging what I know in other languages
> to learn Perl?

Since you've replied to my post, I assume you're addressing this
comment to me, so let me say that I don't remember objecting to
that.
From: Ted on
On Apr 24, 10:10 am, benkasminbull...(a)gmail.com (Ben Bullock) wrote:
> Ted <r.ted.by...(a)rogers.com> wrote:
> >> Try running the following script to clarify what this means:
>
> >> #!/usr/bin/perl
> >> use warnings;
> >> use strict;
> >> my $a;
> >> my $b = "";
> >> print "a is defined\n" if defined($a);
> >> print "b is defined\n" if defined($b);
>
> >> Here $b is a "real null string" and $a is undefined.
>
> Excuse me, this should say '$b is a "defined null string"' not "real".
>
OK. Where does this definition of a defined null string come from?
Wall et al. say nothing about it, either in their chapter two, where
they talk about types and other basic matters, or on page 155 where
they talk about undef.

> > No. $b holds an empty string, and empty strings are not the same thing
> > as NULL (as defined in either C++ and Java or SQL).
>
> But I'm not talking about C++ or Java or SQL. I'm talking about
> Perl. This is a perl newsgroup. "" is what the book you're referring
> to means by a "defined null string", as opposed to an undefined value.
>
Then why are you arguing in this thread.

The DBI is all about mapping SQL concepts to Perl concepts. Surely
this newsgroup is more logical as a place to discuss that than any
other. I'd assume that it was developed by perl programmers to meet
the need to be able to interact with databases.

And where exactly are you getting the idea that the empty string is a
defined null string. Wall et al. certainly make no reference to such
an idea whether where they talk about types in chapter 2 or where they
talk about undefined on page 155. It is, in fact, a bit of a
frustration that they reference the defined null string without
defining it. But I don't criticise them since there is no such thing
as a perfect product, and therefore any product can be improved.

> > But that is exactly what Wall et al. said about undefined.  I learned
> > much of what I know about Perl from their book, and they said that an
> > undefined variable is one that does not have a valid string, number or
> > reference, and that exactly describes a variable that has not yet been
> > initialized.  The empty string is a valid string in all of the
> > languages I use, and it means something quite different from a SQL
> > null.
>
> We're not talking about the empty string any more, the above is
> talking about an undefined value. As I pointed out in the two scripts,
> $b="" and $b=undef are two totally different things.
>
Agreed. But the empty string is not a defined null, unless that
definition is provided somewhere in the Perl documentation. $b in
$b="" is an empty string, neither null nor undefined. Apart from what
you have written here, I have seen nothing written about perl that
equates the empty string to a defined null.

Wall et al. say nothing about an empty string being conceived as being
the same thing as a defined null, either in their second chapter,
where they talk about types and other basic matters, or on page 155
where they talk about undef.

> >> > But ALL of these concepts are very different from the idea of NULL in
> >> > SQL.  For example, The book, from Osborne, "SQL: The complete reference"
> >> > by James Groff and Paul Weinberg, described it as referring to data that
> >> > is missing, unknown, or don't apply.
>
> >> Which seems to be exactly what the undefined value in Perl is, to me.
>
> > Then you're using a definition of the term that is quite different
> > from what Wall et al. wrote about undefined.  Where they wrong, or
> > merely misleading?
>
> Look at this kind of example:
>
> my @arr = (undef, 1, 3, undef, 4);
>
> If you then refer to $arr[3] you get the undefined value. So you can
> assign it into a variable. What is more you can do things like
>
> (undef, $x, $y) = @z;
>
> to ignore the value of $z[0].
>
This is new to me, and quite interesting. And it shows a behaviour
related to the behaviour of SQL NULLs.

> I don't know how that compares to SQL's NULL in detail, but it seems
> to me that this refers to data that is "missing, unknown or does not
> apply", thus from your statement this "seems to be exactly what the
> undefined value in Perl is, to me", as I said.
>
Read Abigail's posts. I found them priceless, and I thank her for
them, for I learned much from her comparison of SQL NULLs and Perl's
undef, especially what she said bout what happens on the Perl side.

> >> > While NULL in SQL is different from
> >> > numeric or string data, I see nothing in the idea that indicates it is a
> >> > value that is not part of the normal range of values.
>
> >> Perhaps you can think of Perl's undef as being part of the normal range
> >> of values, too.
>
> > In principal I'd have no problem with that, if it weren't for the fact
> > that Wall et al. described them as referring to variables that were
> > not initialized.
>
> You keep on and on repeating this but I've already pointed out to you
> that it doesn't mean that. Did you actually try running or even
> reading those scripts I gave?
I repeated it because that is what they wrote, and there seems to be a
gulf between what they wrote and what you're writing. Yes, the
scripts show how Perl behaves in the xample context, but there is a
problem with your example because there is no substantiation of your
claim that the empty string is the same thing as a defined null
string. I do not have a problem with such a definition, but would
like to see it somewhere in the perl documents. Is it given there?
If so, where?

But the notion of a defined null string is really a side issue. It
has become appearent to me from what others have written in this
thread that Perl is doing implicitly, using undef, what I routinely do
explicitly in my C++ and Java code. It also does not address the core
problem that a variable that is not defined is not the same idea as
that represented in an SQL null.

> >> > I see nothing similar between the idea of NULL in SQL and either null or
> >> > undefined in the other languages.
>
> >> That's odd, because the more you talk about SQL's NULL, the more it looks
> >> like Perl's undefined value to me.
>
> > Until now, I had seen nothing written about perl that suggested that
> > Wall et al.'s description of undefined meant anything other than a
> > reference to variables that had not yet been initialized, and that is
> > a very different concept from SQL's NULL.
>
> Please don't say "not yet" again, I've already given you counter
> examples for that.
>
And as I pointed out, your examples that used $a and $b are
problematic, and thus don't settle the question. Further, your
counter examples don't address the fact I have not seen your use of
undefined as being equivalent in meaning to SQL's NULLs in other Perl
references. See Abigail's posts for a detailed explanation of the
problems with such an equivalence.

Yes, I did find the information you referred to on the DBI page, but
there was no explanation there for the rationale behind such a choice.

> > Why would you object to my leveraging what I know in other languages
> > to learn Perl?
>
> Since you've replied to my post, I assume you're addressing this
> comment to me, so let me say that I don't remember objecting to
> that.

You did so implicitly by apparently complaining that I wrote too much
about these ideas as they are reflected in C++ and Java.
To quote what you said above: "But I'm not talking about C++ or Java
or SQL. I'm talking about Perl. This is a perl newsgroup." You seem
to be implying that mention of ideas expressed in C++ or Java or SQL
is forbidden in this newsgroup. If that is correct, it makes it
impossible to leverage what one knows of these other languages to
learn more about perl, and in particular that would make understanding
how and why the DBI maps SQL cncepts to Perl concepts.

If I misinterpreted what you meant by such comments, I apologize.

Cheers,

Ted
From: Ben Bullock on
Martijn Lievaart <m(a)rtij.nl.invlalid> wrote:
> On Thu, 24 Apr 2008 14:10:08 +0000, Ben Bullock wrote:

>> Excuse me, this should say '$b is a "defined null string"' not "real".
>
> No, $b is an empty string. Certainly not a null string. There is no such
> thing as a null string in perl. C++ has a null string concept IIRC, but
> Java and C don't, they allow the variable to be set to NULL, which in
> perl is setting it to undef.

You're taking this phrase out of context. If you go back and read the
previous messages in the thread, you'll see why I used the terminology
"defined null string".

From: Ted on
On Apr 24, 6:31 pm, Martijn Lievaart <m...(a)rtij.nl.invlalid> wrote:
> On Thu, 24 Apr 2008 14:10:08 +0000, Ben Bullock wrote:
> > Ted <r.ted.by...(a)rogers.com> wrote:
>
> >>> Try running the following script to clarify what this means:
>
> >>> #!/usr/bin/perl
> >>> use warnings;
> >>> use strict;
> >>> my $a;
> >>> my $b = "";
> >>> print "a is defined\n" if defined($a); print "b is defined\n" if
> >>> defined($b);
>
> >>> Here $b is a "real null string" and $a is undefined.
>
> > Excuse me, this should say '$b is a "defined null string"' not "real".
>
> No, $b is an empty string. Certainly not a null string. There is no such
> thing as a null string in perl. C++ has a null string concept IIRC, but
> Java and C don't, they allow the variable to be set to NULL, which in
> perl is setting it to undef.
>
FTR, C++ does not have a null string, at least not in the definition
of the language or in the standard C++ library. Like C it uses it to
mark the end of a string, although standard practice is to eschew the
use of C style string arrays, using std::string instead. Compare the
use of the data and c_str member functions of std:;string, if you're
interested. And of course, like C, C++ has the idea of a null
pointer, and this is represented by 0.

If you know of a reference that talks about a null string concept for C
++, I'd love to hear about it (off list, since that probably takes us
too far afield for this forum).

Of course, there is nothing to stop you from representing the idea of
a null string by deriving a new class from std::string, adding a
boolean data member to represent whether or not the instance is
supposed to be null and over-riding any member functions for which you
require specific behaviours of your null string. And of course, you
can do much the same thing in any object oriented language, including
Perl.


Cheers,

Ted

From: Ted on
On Apr 24, 8:27 pm, benkasminbull...(a)gmail.com (Ben Bullock) wrote:
> Martijn Lievaart <m...(a)rtij.nl.invlalid> wrote:
> > On Thu, 24 Apr 2008 14:10:08 +0000, Ben Bullock wrote:
> >> Excuse me, this should say '$b is a "defined null string"' not "real".
>
> > No, $b is an empty string. Certainly not a null string. There is no such
> > thing as a null string in perl. C++ has a null string concept IIRC, but
> > Java and C don't, they allow the variable to be set to NULL, which in
> > perl is setting it to undef.
>
> You're taking this phrase out of context. If you go back and read the
> previous messages in the thread, you'll see why I used the terminology
> "defined null string".

Look Ben, there is no need for a big dispute here. The fact is that
Wall et al. do not define their phrase "defined null string". They
might mean an empty string, they might not. But there is no way to
tell from that book. If you know of another book where they, or
someone else for that matter, give that definition, great. Quote it
and cite it (but give the full citation so I can get an inter-library
loan in order to be able to read it). If there is, in perl, such a
definition, point me to the correct page in the perl docs so I can
read up on it. At present, I have no basis for adequately assessing
what Wall et al. meant by that phrase, because they didn't specify
that in that book. Nor do I see any grounds here to assess whether
your use of such terminology is your own invention or something you
got from some other authority. If it is your own invention, that is
fine and you should say so, but if so you'd be wrong to be upset with
me for not accepting it. If it is something you got from some
authority, then say so and provide me with the references I can use to
find out why that authority introduced such an idea. If Martijn is
right in saying there is no such thing as a defined null string in
perl, then I'd have to infer that Wall et al made a poor choice of
words in their text where they described undefined, and again there is
left no basis for judging whether your use of the phrase is correct,
or if I would be better off to take Martijn's word.

Please, just quote and cite your sources for the idea that the empty
string ought to be equated with a 'defined null string'. I am here
only to learn about perl, and this idea you're expressing is so alien
that I want to know where it comes from and why anyone would think
that it makes sense in some context, or any context, to conflate the
two ideas. Merely repeating your claim that they're the same thing,
and my rejection of such a conflation of distinct ideas, gets us
nowhere.

Cheers,

Ted