Re^2: Why does Perl have typeglobs? (sigils)

[LanX]

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)

[tye]

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.

[LanX]

> 3) a hash by "$sigil.$name" (where the values are of various types)

which is what padwalker returns in a hash.

> but that might not be the best choice in C (and we don't have a complete set of sigils).

I wasn't sure about the pad (thats why I said "at least").

Actually pads are organized more or less like AoA with the first sub-array holding the Sigil+Name keys for each "column". (recursive functions have a row for each recursion, reference Panther book)

But I don't see why changing the first AV with the "sigiled" keys to a HV with indexes to the value AVs shouldt be a problem in C.

> Where did you read the word "need"?

Implicitly. It's an interpretation of how you replied.

You may have meant it differently, but others may not, hence the correction.

[tye]

> Where did you read the word "need"?

Implicitly. It's an interpretation of how you replied.

Perhaps you should read to the end?

What's an obvious way to implement that?

"An obvious way" is very much not "the only way".

But I don't see why changing the first AV with the "sigiled" keys to a HV with indexes to the value AVs shouldt be a problem in C.

Because, as I noted, we don't have sigils for every type of slot in a typeglob. The "in C" part was about there being different value types. To have a value type that could be any of the 6 or so typeglob slot types would be at least complex. It would be complex enough that I would have qualms about that choice.

It turns out that a Perl 5 SV can already be any of those types. But SVs didn't even exist in Perl 4 so they couldn't be how typeglobs were implemented (in Perl 1.0).

The polymorphic SVs are indeed quite complex. The "normal" SV types have much better motivation for how they were done, to my mind, because an SV can transition between those different flavors. Stuffing formats and "IO"s into the polymorphic SV family of structs makes much less sense to me. I couldn't find any part of the Perl source code where this fact was actually useful (I didn't spend that long trying, though) and yet it adds significant complexity, IMHO.

Searching for "PVFM" in the Perl source code mostly finds places where such are not supported.

I'm glad Larry didn't start off trying to implement fully polymorphic SVs in Perl 1.