Root-relative namespace keys

kjstol parrotcode at gmail.com
Wed Jan 7 11:17:03 UTC 2009


On Wed, Jan 7, 2009 at 5:44 AM, Allison Randal <allison at parrot.org> wrote:

> I'm going to start out by taking a step back. First off, define the
> fundamental problem we're trying to solve: accessing classes from
> foreign HLLs. If I've understood Patrick/chromatic, then they agree with
> that.
>
> We're specifically considering several core opcodes:
>
> >>     $P0 = newclass ['Foo';'Bar']
> >>     $P1 = subclass ['Hash'], ['MyHash']
> >>     $P2 = get_class ['MyHash']
> >>     $I0 = isa $P1, ['Hash']
>
> And a :modifier
>
> >>     .sub 'xyz' :multi(['MyHash'])
>
> which currently are a bit too limited in features to adequately handle
> foreign HLLs. I'll put :multi in a separate message.
>
> On general principles, any solution that works for one of the opcodes
> should work for all opcodes that lookup a class. (These opcodes are
> currently consistent, both in how they lookup a class and in how they
> create a class.)
>
> For class lookups 'newclass', 'subclass', 'get_class', and 'isa' all
> accept a string name or a PMC. That PMC can currently be a Key, String,
> ResizableStringArray, or NameSpace. If it's a namespace, the class is
> directly extracted from the namespace. If it's one of the other three,
> then it does a namespace lookup (HLL-relative) and extracts the class
> from that namespace (if it exists).
>
> For class creation, 'newclass' and 'subclass' accept a string name or a
> PMC. The PMC can be a Key, String, ResizableStringArray, NameSpace, or
> Hash. The first four are treated as an HLL-relative namespace lookup,
> with the difference that Key, String, and ResizableStringArray will
> create a new namespace if one isn't found. The Hash contains a 'name'
> element that acts just like the first four, and may also contain
> elements for 'parents', 'methods', 'roles', and 'attributes'.
>
> The class creation behavior isn't unique to 'newclass' and 'subclass',
> it's core behavior of Class itself, and happens any time a Class object
> is created and passed an initialization argument (that is 'init_pmc').
> The 'newclass' and 'subclass' opcodes are just syntactic sugar for:
>
>   $P2 = new 'Hash'
>   # set 'name' and optionally 'parents' keys of hash
>
>   $P1 = new 'Class', $P2
>
> Whatever solution we choose for improving HLL handling with classes
> should fit within this system. And it needs to flexibly handle all
> variations of class lookups in foreign HLLs.
>
> I propose we extend class lookups to also accept a Hash PMC (the code is
> centralized, so it's a straightforward change). Then extend class
> creation so it accepts the same hash keys as class lookups. The keys
> would be:
>
>   - 'name', the class name (string, key, or array of strings)
>   - 'hll', selecting which HLL namespace to use as the root
>   - 'namespace', a namespace object or namespace name (string, key, or
> array of strings)
>
> To lookup a class relative to the current HLL:
>
>   'name' => ['foo';'bar'] # same as ['foo';'bar']
>
> Lookup a class relative to a foreign HLL:
>
>   'hll' => 'lang', 'name' => ['foo';'bar']
>
> Lookup a class relative to any arbitrary namespace object:
>
>   'namespace' => $P0, 'name' => 'foo'
>
>   'namespace' => $P0, 'name' => ['foo';'bar']
>
> Lookup a class relative to a namespace by key or name (looked up
> relative to the current HLL):
>
>   'namespace' => 'my', 'name' => 'foo'
>
>   'namespace' => ['my';'favorite'], 'name' => 'foo'
>
> Lookup a class relative to a foreign HLL, with a namespace key or name:
>
>
>   'hll' => 'lang', 'namespace' => 'my', 'name' => 'foo'
>
>   'hll' => 'lang', 'namespace' => ['my';'favorite'], 'name' => 'foo'
>
>
>
> Someone is probably going to say "but creating a Hash to pass as an
> initializer is a pain in PIR". Yes, it is. It always has been a pain.
> And it's a pain that isn't unique to PMC initialization, but true of all
> hash creations everywhere. Making a list is really easy with
> ['foo';'bar'] or 'split', but making a hash is just a pain. The only
> place creating something hash-like isn't a pain is in a method call.
> Okay, so maybe this is a good problem to solve once for everyone.
>
> What if we reuse the parsing for that method call syntax to create a
> Hash (or Capture)? And make it legal anywhere a PMC argument is legal?
> So, that pseudocode above becomes the actual code:
>
>   $P0 = newclass ('hll'=>'lang', 'namespace'=>'my', 'name'=>'foo')


Please note the following, before fixing things. (it's just syntax, not that
important)
This looks extremely similar to an invocation of the sub 'newclass', (or the
sub stored in a .local pmc newclass, if declared), with an argument list,
and returning 1 PMC value. Consider a random other statement in its
proximity:

$P0 = foo  ('hll'=>'lang', 'namespace'=>'my', 'name'=>'foo')

People will be confused and ask: what's the difference.
Given that this new syntax is in fact new sugar (being a way to shortcut
multiple lines of PIR), 2 things pop up in my mind: 1) require a comma
between 'newclass' and the hash initializer. Or, 2) write the initializer in
{ and } braces. Braces always make me think of hashes, and I think it's Perl
syntax as well.

2 cents of your syntax police :-)

kjs

>
>
> Or, just creating a Hash:
>
>   $P0 = new 'Hash', ('foo' => 1, 'bar' => 2)
>
> Or maybe even:
>
>   $P0 = ('foo' => 1, 'bar' => 2)
>
> I used parens for the parallel with method calls, but the contexts are
> different enough that it may be a bad parallel. It could equally well
> use '|...|' or some other bracketing characters. I would avoid '[...]'
> for the sake of confusion, it does something completely different. But,
> it's important to be consistent on the syntax inside for "named lists",
> that is, key/value pairs.
>
>
> This feels flexible, it feels dynamic, and it doesn't feel hackish.
> Thoughts, comments, variations on a theme?
>
> Allison
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.parrot.org/pipermail/parrot-dev/attachments/20090107/cd89c063/attachment.htm 


More information about the parrot-dev mailing list