Matt Diephouse wrote:
So for the runtime (this is the HLL runtime, not the PIR runtime, btw)
we're all set. Arrays fill the need perfectly and let us access the
root HLL namespace. That makes me think that we don't need any new
opcodes.
Chip's latest simplification eliminates the need for creating and
passing in an empty array, because 'no argument' always means the same
thing as 'empty array' or 'no key' would mean. That's a really elegant
piece of consistency.
And I think it's a worthy goal to make
compiler writer's lives good.
I agree.
Adding 0-dimensional keys would also let us get rid of the C<
.namespace > special case and replace it with C< .namespace [] >.
Hmmm... if we're preserving parallels, that could be C< $P0 =
get_namespace > and C< .namespace >
It's simpler to give the root HLL namespace a name.
I disagree on two counts here.
And I've moved on to "the root HLL namespace doesn't need a name if you
disambiguate by marking the verb (that is, the opcode)."
First, I think C< [] > *is* a name.
Yes, in using C< [] > to mean "access the root HLL namespace" we would
be treating it as a name. Or more like a method call. It's a magical bit
of syntax that would be appropriate in a HLL, but seems out-of-place in PIR.
Second, any solution which involves giving the HLL namespace a
different name will have to either (a) add new opcodes, (b) add more
code for all the other cases by making all referencing originate at
the root, or (c) add a special syntax, none of which is simple.
To add a new feature, we have to add some extra syntax somewhere. I'm
most comfortable with (a) here, because it targets the change at the
problem in a straightforward fashion.
Allison
