Phoenix.pm: definedness and more symbol tables

Beaves at aol.com Beaves at aol.com
Fri Jan 21 17:14:36 CST 2000


I just thought I'd share some stuff I learned with y'all during my symbol 
table excursion.  Some of the testing on my little sub did not go as 
expected.  I couldn't understand why, but I think I figured it out.

If there is something that I say here that is in dispute, please bring it up. 
(I'm using package 'main' for all examples...)


    On initial parsing of a program, symbol table entries are made for each 
symbol (I'm guessing for efficiency).  Even if there is no assigment, there 
will be a 
    $main::{symname}
entry made to the symbol table, and a reference to the variable created.
For instance, just saying.
    @symname;
creates
    $main::{symname}
and a reference to the ARRAY for symname in the glob.
    *main::symname{ARRAY}  
Of course, the value it is pointing to is still undefined, but 
*main::symname{ARRAY} is itself defined.

Hashes and Arrays are 'undefined' until the memory is allocated for them.  
This is an interesting point.  See below
    @symname;  #undefined
    @sumname = ();  # still undefined;
    @symname = (1)  # now its defined...
# but if you say
    shift(@symname);  # @symname is STILL DEFINED
# even if you say
    @symname = undef;  #@symname is STILL DEFINED (memory still allocated)
# same is true for hashes

The definedness of subroutines has to do if the code was successfully parsed.

Saying
defined $symname;
will not create a symbol table entry.  However, if this statement is made on 
parsing, it WILL create a symbol table.
Consider...
    defined $symname;  # symbol table entry created on parsing this code, not 
when running it
    delete( $main::{symname});
    defined $symname;  # does not create a symbol table entry.

This stuff is not really that important, but I thought that I'd share what I 
discovered.

Sorry for boring you'all to tears.

See you round campus.

Tim




More information about the Phoenix-pm mailing list