That's wrong, the variable is still in the symbol table, it's value is just undef.

In FAT if you delete a file from the directory it is still present but marked as deleted.

So the fact that it is still present does not change the fact that semantically it is deleted.

In other words, if the item in a Perl symbol table has value undef for all practical purposes is it that same as deleted item in FAT and should be treated by interpreter developers in the same way as "not found" item.

In FAT if you delete item from the directory it is still present but marked as deleted.

So the fact that it is still present does not change the fact that semantically it is deleted.

Further to stevieb's and haukex's comments:   In a file system, if you delete a file and then create another file with the same name, do you get any warning that the old file still, in any sense, "exists", or "masks" anything, or that there is any possible symbol/name collision? The symbol spaces of Perl are not file systems.

c:\@Work\Perl\monks>perl -wMstrict -le
"my $scalar = 42;
 undef $scalar;
 my $scalar;
"
"my" variable $scalar masks earlier declaration in same scope ...
[download]

Of course, this message is only emitted if warnings are enabled, but it highlights the fact that an undef-ed scalar still very much exists. (Same behavior with our package-global scalars.)

I think the critical point that you miss is that undef is a very well-defined value! It is not random, it can be tested, scalars having that value exist in every sense, etc.

---

Give a man a fish:  <%-{-{-{-<

In other words, if the item in a Perl symbol table has value undef for all practical purposes is it that same as deleted item in FAT and should be treated by interpreter developers in the same way as "not found" item.

No, that's an incorrect analogy. Assigning undef to a scalar is like truncating a file down to zero bytes - it still exists as before, just its content has been cleared. (Not to mention that lexicals aren't even in the symbol table. See perlmod for the details.)

"In other words, if the item in a Perl symbol table has value undef for all practical purposes is it that same as deleted item in FAT and should be treated by interpreter developers in the same way as "not found" item. "

Might I ask where you got your information that Perl variables are relative to a file system designed in the 80's?

In other words, before you make statements that relate the two together, you should at least test on another 3-4 programming languages and see how things are dealt with there first.

At least that's what I'd do before making blanket complaints.

Have you filed a bug report for this 'issue' with the p5p team?

  DB<64> p exists $main::{X}

  DB<65> $X = undef

  DB<66> p exists $main::{X}
1
  DB<67>
[download]

> Do not shoot the piano player, ... :-)

Why would I?

I'm not aware that Charles Aznavour spread fake news about programming ...

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

Thank you ! It is always a pleasure to see your replies.

But it is a bad practice to use a key in hashes without quotes, as in $main::{X} ;-)

A more revealing variant of your test would be

[0]  # cat undef_exists_test.pl
use v5.10;
say $main::{'X'};
say $X;
say $main::{'X'};
if( exists $main::{'X'} ){ say "exists";} else {say "does not exist";}
if( defined($X) ){say "defined";} else {say "not defined";}

$X=1;
undef $X;
if( exists $main::{'X'} ){ say "exists";} else {say "does not exist";}
if( defined($X) ){say "defined";} else {say "not defined";}

Running it I got:

*main::X

*main::X
exists
not defined
exists
not defined

[0]  #

We can see that even before the statement "say X;" executed the variable X was already added to the symbol table (during begin block execution?),

So it does exists.

NOTE:

I think undef is not a value, as many here assume, but a function, So

$X=undef;

actually means in Perl:

$X=undef();

and is equivalent to

undef $X;