>Perhaps it would be better to have Perl support all of perlfunc(1) in the
>core still, but allow users to turn subsets off?
>Or, perhaps the core functions could be syntactic sugar for access to
>modules, and have a transformation happen automagically in the parser? (My
>gut says "here there be dragons", but they don't seem like dragons that are
>unslayable.)
One might consider making CORE:: a real-er namespace. In Python, for
example, with its semi-numbskulled non-nesting scoping levels,
you still have three resolutions: builtins (read: CORE), package, and
local. These are all fully-fledged namespaces, and you could store
something in the builtins if you wanted. Somewhat like CORE::GLOBAL.
Right now, of course, you can't usefully do much with \&CORE::dbmopen,
for example. But if you could, perhaps more would be feasible.
However, I feel that I may run the risk of violating the following:
"We do not define Perl as an improved version of some other
language. Nor do we define Perl as the next universal language.
We're not trying to make Perl a better language than C++, or
Pyuthon, or Java, or JavaScript. We're trying to make Perl a
better language than Perl. That's all."
--Larry Wall in his 1999 State of the Onion Address
But if I am doing so, then it is not without ample precedent in this
and related threads. :-(
--tom
