[perl #40058] Disambiguate usage of class PMCs from class name lookup (pdd15, pdd06, pdd19)
Chip Salzenberg
# Please include the string: [perl #40058]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40058 >
The new 'subclass' opcode variants demonstrates the inherent ambiguity
between class names and class PMCs; merely being a PMC or not isn't enough
to distinguish the intent of specifying class vs. class name. (Keys are
PMCs.) This should be resolved in a general way for all class-accepting
opcodes.
CURRENT STATE OF PLAY
There are currently five distinct ways to identify a class, some or all of
which are used by various opcodes:
(1) Class PMC itself (in P reg)
(2) INTVAL type number (I reg or integer constant)
(3) STRING type name (S reg or string constant)
(4) String PMC type name (String PMC in P reg or PMC constant)
(5) Key PMC type name (Key PMC in P reg[*] or PMC constant)
[*] The P reg version of this is new in my latest changes.
It's not used widely (if at all), and only works for
selected opcodes.
KNOWN FUTURE DEVELOPMENTS
It's already decided that we're moving class PMCs into the normal namespace
tree. This change will eliminate many uses of the class-lookup opcodes, but
not all: There's a two-level search will still be required, where the
universal ['parrot'] HLL provides the fallback for class names not defined
locally -- e.g. C<find_type ['Integer']> could return ['yourHLL';'Integer']
if you've defined that, or else ['parrot';'Integer'] if you haven't.
SUGGESTIONS
I. Opcode cleanup
It seems to me that we should carefully distinguish two types of opcodes:
(a) opcodes that use class PMCs or numbers
(b) opcodes that look up class PMCs by name, and return a PMC or a number
Type A opcodes would use lookup methods 1 and 2.
PMC parameters would always be class PMCs.
Type B opcodes would use lookup methods 3, 4, and 5.
PMC parameters would always be names.
II. Eliminate simple string names for classes, using Keys exclusively
There's little reason IMO to continue to support simple strings for class
names; it multiplies opcodes for the special case of simple class names.
Always using keys would serve as well.
--
Chip Salzenberg <ch...@pobox.com>
Martin D Kealey
> KNOWN FUTURE DEVELOPMENTS
>
> It's already decided that we're moving class PMCs into the normal namespace
> tree. This change will eliminate many uses of the class-lookup opcodes, but
> not all: There's a two-level search will still be required, where the
> universal ['parrot'] HLL provides the fallback for class names not defined
> locally -- e.g. C<find_type ['Integer']> could return ['yourHLL';'Integer']
> if you've defined that, or else ['parrot';'Integer'] if you haven't.
Any reason to treat HLL namespaces differently from classes, at least in
respect of being an inheritance hierachy? Simply make 'yourHLL' inherit from
'parrot', and the rest follows...
-Martin
Chromatic
> Any reason to treat HLL namespaces differently from classes, at least in
> respect of being an inheritance hierachy?
Preventative measures against future additions to 'parrot' breaking your code
without your knowledge. It's the same reason many languages without
namespaces or sigils have a sense of reserved keywords.
> Simply make 'yourHLL' inherit
> from 'parrot', and the rest follows...
I wouldn't do this in any language I write.
-- c
Martin Kealey
> > Any reason to treat HLL namespaces differently from classes, at
> > least in respect of being an inheritance hierachy?
> Preventative measures against future additions to 'parrot' breaking
> your code without your knowledge. It's the same reason many languages
> without namespaces or sigils have a sense of reserved keywords.
The naive reaction to this is that if you define ['myHLL';'foo'] then
whether ['parrot';'foo'] is defined (or later becomes defined) is of no
concern.
However there are two cases I can see where ['parrot';'foo'] must NOT
exist:
1. if myHLL needs to search by some other order, such as the first of:
['myHLL';'foo']
['myHLL';'bar']
['parrot';'foo']
['parrot';'bar']
2. if myHLL does not actually define ['myHLL';'foo'] but then checks to
see if it's usable, and would find ['parrot';'foo'] via the normal
inheriting framework.
But how often are these actually likely to be the case, and are there
any other cases?
-Martin
Chromatic
> The naive reaction to this is that if you define ['myHLL';'foo'] then
> whether ['parrot';'foo'] is defined (or later becomes defined) is of no
> concern.
If my code depends on the undefinedness of certain symbols, and those symbols
may or may not appear in some namespace somewhere due to something totally
unrelated to my code, I have a problem.
> 2. if myHLL does not actually define ['myHLL';'foo'] but then checks to
> see if it's usable, and would find ['parrot';'foo'] via the normal
> inheriting framework.
> But how often are these actually likely to be the case
All the time, in Pheme. In a very late-binding language, without performing
any external analysis, can you tell if this is a cons or a function
applications?
(foo bar baz)
It's easy in some cases:
('foo bar baz)
(quote (foo bar baz))
It's harder in other cases; it depends on the other symbols available at the
point of evaluation. (You can cheat a little bit at compile-time, if you
disallow symbol removal; cache the define-lambda pairs and store those names
away. Then you can peek at the first atom in a cons to see if it's a defined
symbol or a built-in and avoid the runtime lookup.)
If the answer to that question depends on which version of Parrot people have
installed and it's not a bug in my implementation, but rather symbols leaking
out of the Parrot namespace, that makes my job much more difficult.
Try debugging that.
I don't care for the argument that "It won't happen very often", when it
doesn't have to happen at all and it can cause big, difficult-to-diagnose
problems.
In fact, I can't think of any language port that would *want* Parrot symbols
exposed so easily. Perhaps a new language would, but to my mind that
language would look an awful lot like PIR....
-- c
Martin Kealey
> may or may not appear in some namespace somewhere due to something totally
> unrelated to my code, I have a problem.
Ah. I thought we were considering the namespace which the language would use
for its implementation, not for the namespace in which it would keep its
client script's symbols. That being the case, your reservation eminently
makes sense.
But I didn't expect to see "PerlArray" as a reserved name in Perl 6, so I
assumed we weren't talking about *that* namespace.
-Martin