For example, the following adds bar to the symbol table after Mod.pm has been executed.

use Mod;
sub bar { ... }
...
[download]

Perl doesn't have to expose the type globs to the program, but it makes some incredible things possible. A simple example is aliasing a sub.

sub foo { ... }

*Foo = \&foo;  # Create alias for backwards compatibility.
[download]

Yes, but my question wasn't why Perl have symbol table entries. It was why they are structs with a bunch of pointers to different things: arrays, scalars etc... rather then one pointer to one thing per struct. I came to the conclusion that it was some attempt to gain effeciency... assuming that programmers would actually use that feature (reusing variable names; for ex. $foo, @foo, %foo etc). I don't think that too many people actually do that, am I wrong?

It was why they are structs with a bunch of pointers to different things

Perl can have arrays, scalars, hashes, etc with the same name. Therefore, the symbol table entry for a name must be able to hold all of them.

I don't think that too many people actually do that, am I wrong?

It doesn't matter how many do. It just matters if they can. That said, virtually every program uses both $_ and @_. The numerous programs using <> use $ARGV, @ARGV and *ARGV{IO}.

You can e.g. assign a typeglob to another:

$foo = 42; @foo = ( 1, 2, 3 );
*bar = *foo;
print "$bar @bar";
undef *bar;
print "$bar @bar";
[download]

Where and why that might come useful I cannot tell; however, it does make sense to keep a single struct, does it not?

Perl has typeglobs because Perl has sigils. A typeglob would make no sense in a language where you write:

    string s;
    array  a;
    hash   h;
[download]

But a typeglob makes sense in a language where you can say:

    our( $stuff, @stuff, %stuff );
    open *stuff, ...;
    &stuff();
    write stuff;
[download]

Looking in the symbol table under the single name "stuff", you might find 6 different things. What's an obvious way to implement that?

You don't need typeglobs to handle sigils, lexical pads work without the "hash of slot" structure of STASHes.

(well at least does padwalker not return such a structure, variables are in the hash with sigil as part of the name)

Cheers Rolf

(addicted to the Perl Programming Language)

Where did you read the word "need"?

If you want to use Perl's PADs as part of an argument against how symbol tables were implemented, then you probably should learn more about Perl's PADs first. Perl's PADs don't support looking things up by name so they'd really suck as an implementation of a symbol table. That's why that module has "walker" in its name. Plus PADs only support about half of the slot types of a typeglob.

The obvious two choices are 1) a hash by name where each value has N slots for N types of things; 2) N hashes. If you have a complete set of sigils, then the third obvious choice is 3) a hash by "$sigil.$name" (where the values are of various types) but that might not be the best choice in C (and we don't have a complete set of sigils).

The choice of typeglobs is more obvious in older features of Perl where "open FOO" then "write FOO" will use $FOO as the name of the file to open, *FOO as the handle to open, and FOO as the format to write. Even more slots of *ARGV are used together.

- tye        

A long time ago, it was a way to carry around filehandles. Perl 5.8 (I think) allowed lexicals to hold filehandles, so this use died out.

Most useful thing I've found is to make a list of simple accessors in a class:

{
    my @ACCESSORS = qw{ foo bar baz };
    for my $slot (@ACCESSORS) {
        no strict 'refs';
        *$slot = sub {
            my ($self) = @_;
            $self->{$slot};
        };
    }
}
[download]

But even this has tended to go away with meta-object systems like Moose (which do similar things under the hood).

This was (sort of) asked and addressed a while back at What are typeglobs (useful for)?. I was introduced to the Union data structure in my college compiler class for what it is worth. I have always thought of typeglobs as Unions -- things that can store the same value but reference/use it in different ways. I'm probably wrong, however. :)

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

Actually, typeglobs are more like structures than unions. Symbol table entries have a name field plus a value field for each type of value.

As for why the Perl symbol table was designed this way, my guess is that it was just easier to manage only one entry per name and, similarly, only one symbol table per package.

Personally, I think it would have been simpler to only allow a given symbol to be one type of value, that of its first use. Since this is in line with best coding practices, it would have been a reasonable design choice.

Why does Perl have typeglobs? Yes, I understand that they are symbol table entries, but why can they hold several completely unrelated things - scalars, arrays, filehandles?

Because they are symbol table entries ... the symbol table, where completely unrelated things (variables) are held

If they weren't in the symbol table, they would be in the lexical pad (symbol table)

Is there some technical reason for that?

Yes, its drawn that way

Or was that just Larry's idea?

Larry , like all great inventors, borrowed lots of good ideas, and then he drawn-ed it

So, yeah, why are typeglobs the way they are?

Because

If they weren't the way they are, what way would they be?

SCALAR_table
ARRAY_table
HASH_table
CODE_table
IO_table
FORMAT_table
[download]

Hmm, six individual variables tables, versus one umbrella table, hmmm

Why does perl have sigils to begin with? Or compact syntax for patter matching?

:P

Because they are symbol table entries ... the symbol table, where completely unrelated things (variables) are held

You know, Perl is not the only programming language that makes use of symbol tables! And other language (that I know of) dont have anything like typeglobs.

Hmm, six individual variables tables, versus one umbrella table, hmmm

? Why would you need different symbol tables? Different keys for different things would suffice. Perl's symbol table is just a hash... (well, I would be REALLY surprized if it weren't so)

But now that I think of it, yeah... It was probably an attempt to save memory. Smaller symbol tables, fewer structs in them, fewer calls to malloc... That kind of fits with the idea context. Still pretty strange. I'm sure Perl programmers don't use that feature very often, if at all.

Perl's symbol table is just a hash

Indeed. A hash of hashes, in a way:

use warnings;
use strict;
sub T { 42 }
our $T = 24;
*T = *STDOUT{IO};
print { *T{IO} } ${*T{SCALAR}}, ' ', *T{CODE}->(), "\n";
[download]

لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ

Symbol tables are common in LISP the oldest dynamic language, so you might rather ask why LISP does it that way.

I suppose it was done like this because this language prefers linked lists over lookup tables (like "hashes")

So having just one lookup table for all data types seems reasonable.

You might rather want to ask Larry why lexical variables were NOT stored in a similar structure after their introduction to Perl 5.

If you had posted this response with a user name I would happily up-vote it, it is a good response to the people who have replied to you. But I see no point in wasting a vote on the Anonymous Monk. (And if someone knows of a good reason to do so I'll listen.)

You must always remember that the primary goal is to drain the swamp even when you are hip-deep in alligators.

But I see no point in wasting a vote on the Anonymous Monk. (And if someone knows of a good reason to do so I'll listen.)

The rulesruels of the game are, ++upvote nodes you like, not people you like ... PerlMonks FAQ -> How should I spend my votes? -- General Voting Guidelines

There is a quote in a signature around: Examine what is said not who speaks

It is understandable not to spend votes thank-you/summary type of nodes (like the case here), but the votes are never wasted on good nodes

Hi :)