Root-relative namespace keys
Andrew Whitworth
wknight8111 at gmail.com
Thu Jan 22 13:12:37 UTC 2009
On Thu, Jan 22, 2009 at 5:40 AM, kjstol <parrotcode at gmail.com> wrote:
>
> I've been thinking a bit on how to implement this. PIR would become too high
> level, in my opinion, if we'd allow writing these constructors everywhere a
> PMC can be written.
> So, this, is too complex:
> foo({1, 2, 3}) # sugar for new $Px, "Array"; $Px[0] = 1; $Px[1] = 2; $Px[2]
> = 3
> There's just too much going on on 1 line, I think. (Not too mention the fact
> that the Array would be stored in the constants table, which means it
> becomes a "_pc" signature in an op, as it refers to a PMC Constant. Messy.
> Therefore, maybe it would be a good idea to introduce an initialize
> directive:
> .init $P0, {1, 2, 3}
When I wrote that last email, I had in mind that it would be a huge
pain in terms of parsing. But, I like this solution you have very
much. I don't think we need to have the ability to insert a PMC
constant everywhere we can currently insert a PMC. A .init directive
could be very handy in these cases, but if we're using a special
directive every time we initialize a PMC like this we don't need to
also use a special Curly-Bracket syntax to set them apart. We could
use something like a key syntax instead:
.init $P0 [1 ; 2 ; 3]
Or maybe with a slight extension:
.init $P0, 'Array', [1 ; 2 ; 3]
to specify type. We don't need to do much extra work to handle parsing
since we already parse keys correctly. The init directive would just
have to contain an ability to convert a key into the specified type
(possibly through an interface like morph, or through a role like
"does pmc_init"). In this case, we could easily use an opcode instead
of a new directive ("initpmcconst"?), and not have to monkey with the
parser at all.
--Andrew Whitworth
More information about the parrot-dev
mailing list