Root-relative namespace keys

[kjstol]

On Fri, Jan 16, 2009 at 3:29 PM, Andrew Whitworth <wknight8111 at gmail.com>wrote:

> I thought I had sent out a reply to this post a little while back, but
> looking through the archives it doesn't look like I actually did
> (which would explain the complete lack of responses!)
>
> On Tue, Jan 6, 2009 at 11:44 PM, Allison Randal <allison at parrot.org>
> wrote:
> > 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')
> >
> > 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.
>


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}

which is basically sugar for:

$P0 = new "Array"
$P0[0] = 1
$P0[1] = 2
$P0[2] = 3

(and then use it:
$Px = new "Foo", $P0 # $P0 contains the init object.
)

(maybe even throw some stuff in that Andrew++ suggested -- see below -- ,
for indicating the type; alternatively, use {"a" => 1, "b" => 2} for hash
construction. Anyway, details).

This would mean, that a new Array (or hash, or whatever, but for this
discussion let's stick to Array) is constructed during compile time (as you
know the contents). It's stored in the constant table, and you can refer to
it through $P0.
Underneath, it could be as simple as a set_p_pc op, which sets $P0 to the
constant that contains that array.

This way, the syntax changes stay small, and the grammar is not becoming too
complicated.

just a thought.

kjs

>
>
> What if, instead of reusing parens for this we use the as-yet-unused
> curly brackets? Also, now might be a great time to consider the use of
> general-purpose PMC literals, instead of a special case that only
> allows hashes? Using prefix modifiers like we do for strings to
> specify the PMC type, it would look something like this:
>
>  FixedIntegerArray:{0, 2, 3, 4}
>  Array:{"a", "b", "cde"}
>  Hash:{"first", 0, "second", 1"}
>  Integer:{5}
>
> Alternatively, we could use postfix adverb syntax:
>
>  {0, 2, 3, 4} :array('ResizableIntegerArray')
>  {1, 5, 6} :array
>  {"first", 1, "second", 2} :hash
>  {"first", 1, "second", 2} :hash("OrderedHash")
>  {1} :scalar("Integer")
>  {"hello"} :scalar("String")
>
> This would give us a nice and flexible way to specify PMC constants
> that could be extended to cover most basic PMC types (Integer, Float,
> String, anything that "provides array" or "provides hash") and it's a
> syntax that wouldn;t be too hackish or too special-purpose.
>
> --Andrew Whitwort
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.parrot.org/pipermail/parrot-dev/attachments/20090122/130563af/attachment.htm