On Thu, Oct 19, 2006 at 11:20:56PM -0400, Matt Diephouse wrote:
> Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> > On Thu, Oct 19, 2006 at 10:01:29PM -0400, Matt Diephouse wrote:
> >> ATM, all classes go into the 'parrot' HLL. [...] I'm pretty sure
> >> that HLL classes will have to go into the HLL's root namespace (this
> >> needs to happen anyway to prevent namespace pollution). That leaves us
> >> with the question of how to differentiate core PMCs from HLL PMCs. I'm
> >> not sure how to handle that, but that's what a spec is for.
> >
> >Why is the differentiation necessary -- wouldn't "core PMCs" simply
> >be part of the 'parrot' HLL?
>
> That's the place to put them. But how do you make the core PMCs
> visible to the compiler and not to the user?
Two off-the-top-of-my-head possibilities:
1. Reference core PMCs by their .ClassName constants as opposed
to their stringified names. Then stringified names are _always_
hll classes.
2. Provide an opcode that allows us to lookup class names
in other hlls; i.e., allow the equivalent of things like
$I0 = find_type [ 'parrot'; 'String' ]
$P0 = new $I0
$I0 = find_type [ 'pge'; 'Match' ]
$P1 = new $I0
> Perhaps this will be clearer if I demonstrate with code. I imagine
> that this Perl 6:
>
> my $obj = Perl6Object.new()
>
> will translate to something like this PIR:
>
> .lex '$obj', $P0
> $P0 = new 'Perl6Object' # do Perl6 classes have sigils?
> $P0.INIT()
(If Perl6 classes have sigils, it's probably '::', just like package names.)
Actually, now that you mention this, perhaps it would end up
being more along the lines of:
.lex '$obj', $P0 # declare lexicaly scoped '$obj'
$P1 = find_name 'Perl6Object' # find class for 'Perl6Object'
$P0 = $P1.'new'() # send 'new' message to Perl6Object
and then the 'new' method of the 'Perl6Object' class (likely inherited
from a base 'Class' type in Perl6 hll-space) takes care of finding
the correct Parrot object type, calling Parrot's C<new> opcode with
that type, invoking INIT, and returning the resulting object to be
placed in $P0.
> But that means if the user writes this Perl 6:
>
> my $obj = ResizablePMCArray.new()
>
> this PIR will be generated:
>
> .lex '$obj', $P0
> $P0 = new 'ResizablePMCArray' # oh no! this isn't an actual Perl6
> class - it's namespace pollution!
> $P0.INIT()
>
> We need to somehow differentiate between Perl6Object and
> ResizablePMCArray. Especially given the possibility that the user will
> write this:
>
> class ResizablePMCArray { ... }
There aren't any barewords in Perl 6, so all bare classnames have
to be predeclared in order to get past the compiler, and then it's
fairly certain we're talking about a Perl 6 class and not a Parrot
class.
I suspect that if the Perl 6 programmer really wants to be using
the Parrot ResizablePMCArray, it will need to be imported into
the perl6 hll_namespace somehow, or otherwise given enough details
so that perl6's 'ResizablePMCArray' class object knows that it's
the Parrot class and not the Perl6 one.
> This isn't too much different from using keyed class names like
> ['pge'; 'Closure'] like you guessed in your first email. But this
> places classes next to their namespaces, which is a good thing. But we
> probably do need keyed class names to support this:
>
> class Foo::Bar { ... }
I'm expecting that both PGE and perl6 will be translating names
like "Foo::Bar" into an array of [ 'Foo'; 'Bar' ], and then looked
up relative to the current namespace.
All of which might seem to indicate that 'class is a namespace' is
the right approach, or at least that perl6 will be modeling it that way.
Thanks, Matt -- this is turning into a really helpful and useful
discussion, at least for me.
Pm
