Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
On Thu, Oct 19, 2006 at 10:01:29PM -0400, Matt Diephouse wrote:
> This is unspecced. ATM, all classes go into the 'parrot' HLL. This is
> a relic of the past and I think it needs to change. 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? I expect the Perl 6
compiler will want to use a ResizablePMCArray in places without making
it a builtin Perl 6 class. But how can you if there's only one new
opcode?
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()
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 { ... }
Does that break the compiler when it tries to create a
ResizablePMCArray to use internally? Or die because there's already a
ResizablePMCArray class? Remember that no matter how much name
mangling you do in this case, there's probably a language that doesn't
want to do any.
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 { ... }
HTH,
--
Matt Diephouse
http://matt.diephouse.com
