The simple answer, which is probably "right" for much of the audience is to explain undef and how you test for it. For someone fetching a row of fields out of a database, where some of the field can be NULL, this answer is good enough.

Where this answer goes awry is in SQL comparison semantics. In SQL, you test for the presense of NULL using an "IS NULL" clause, because NULL is never equal to NULL. A frequent source of SQL newbie errors is preparing   SELECT a FROM t WHERE b = ? and then binding NULL (or undef) to the placeholder. No go. One needs to write   SELECT a FROM t WHERE b IS NULL Granted, this is a SQL problem and not a Perl problem, but it's lurking there waiting to bite the uninformed. In my opinion, it's worth mentioning whenever any asks about how to do NULL in Perl.

The simple answer, which is probably "right" for much of the audience is to explain undef and how you test for it.

You show your SQL bias as much as djantzen shows his C bias!

There is no "right" answer for "much of the audience", except to ask what is meant. And that's my original point. My litany of possible responses is meant to describe how many "right" answers there could be possibly, and no answer is more right than any of the others, except determined by context!

-- Randal L. Schwartz, Perl hacker

1. The phrase 'NULL string' has a well-known and precise meaning in C ('""').
   
   
2. Whatever meaning this phrase has in SQL is derived from it's meaning in C. It does not have the well-known and precise meaning in the former as in the latter and the question 'How do I test for a SQL NULL string?' is better rephrased 'How do I test if a char/varchar field declared 'NULL' contains a C-style NULL string ('""')?'.
   
   
3. Employing the eminent philosopher of language Donald Davidson, I introduce "the principle of charity", according to which a listener wishing to interpret a speaker accurately "must maximize the self-consistency attribut(ed) to him, on pain of not understanding him" (From "Truth and Meaning").

While the term 'NULL' is obviously part of SQL, and it is not impossible to define the phrase 'NULL string' within the semantics of SQL, it does not follow that it is equally likely that the questioner was in fact importing those semantics rather than the semantics of C.

Similarly, although the romance languages share cognates derived from Latin, take libre for example, when I speak Spanish I am not also speaking French by virtue of the shared term. In such a situation the listener must determine from the context which language I am speaking. If I make the utterance "Creo en habla libre, y cerveza gratis", it is wholly incorrect to believe that I am speaking French, but poorly, because an interpretation of the utterance that attributes self-consistency to me is available. To conclude that I am speaking French on the basis of the appearance of "libre" is to attribute to me a great deal of nonsense surrounding that one term, and this is not sound interpretation.

Therefore, because there is a well-known and precise meaning available to the phrase 'NULL string', and because I believe that the principle of charity will yield in general better interpretation, to conclude that the speaker refers to it's meaning in C is a reasonable conclusion, indeed, more reasonable than any other, including SQL.

Now according to merlyn's clarifications, his point is that the listener must be sensitive to different meanings possibly at work in a question. This is fine, however I would suggest that an orthogonal pressure here ought to be the principle of charity. It is better to risk thinking too highly of your interlocutor than to assume immediately that his utterances are largely nonsense. If the point here is not to give a real answer to the question 'How do I test for a NULL string', for which there is a sensible answer in Perl, but to give an exhortation to be careful about importing meanings carelessly across language boundaries, then I suggest the question be rephrased in such a way that the principle of charity not demand a particular interpretation. The rather more innucuous "How do I test for a string that is null?" would make the point better.

..is to explain undef and how you test for it.

Problem being

my ($x,$y);
print "Same!" if $x==$y;
__END__
Same!
[download]

Since it doesnt follow the properties of the SQL null i'm not real sure why explaining undef will help any more than explaining an empty string.

Yves / DeMerphq
--
When to use Prototypes?

Michael

This is trivially true. You are essentially saying that the question is nonsensical because 'NULL' is not a reserved word in the Perl language. However, it is evident that the questioner comes from a C background, in which the phrase 'NULL string' has a well-defined meaning with a suitable analogue in Perl -- that is, the string that contains no characters, or '""'.

You are essentially saying that the question is nonsensical because 'NULL' is not a reserved word in the Perl language.

No, I'm saying more than that.

However, it is evident that the questioner comes from a C background,

No, it could also be an SQL background.

in which the phrase 'NULL string' has a well-defined meaning with a suitable analogue in Perl

No, because even NULL in C could mean NULL pointer, which is closer to undef than to an empty string.

You have just proven my point. You assumed things that cannot be assumed. Therefore, the question is unanswerable without further information. A good question answerer understands how many different context things apply. And personally, I've seen people use NULL to mean every single one of those items in that list I give.

-- Randal L. Schwartz, Perl hacker

No, because even NULL in C could mean NULL pointer, which is closer to undef than to an empty string.

Quite true, in which case the appropriate phrase would be 'NULL string pointer', or maybe 'NULL pointer to a string', but that's not how the question is stated. Now I understand the need to be sensitive to context when interpreting a question, however when I first read your post I thought you were giving a general answer suitable to a well-phrased query. If this whole debate turns on your interlocuter not knowing precise terminology, then there's really no point to this.

Howdy!

No, it is not 'trivially' true. It is a fairly precise response to the question that solicits clarification of just what is being asked.

The querant can then refine their question to allow a meaningful reply, assuming their apparent ignorance is actually treatable. Note that 'ignorance' is not used in its pejorative sense but in a simple descriptive sense.

I like merlyn's response. It offers the beginning of a dialog that can lead to more than a simple answer to the poorly worded question.

yours,
Michael

NULL in what context?

--Jim