Allison Randal <[EMAIL PROTECTED]> wrote:
Matt Diephouse wrote:
> 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?
If we have a strict separation between the HLL namespace and the Parrot
namespace (and I think we should), then the only way instantiate a core
Parrot class/PMC from within an HLL is to first retrieve the 'parrot'
namespace, and preferably through the typed interface. Speculatively:
$P0 = get_root_namespace ['parrot']
$P1 = $P0.find_class('ResizablePMCArray')
$P2 = new $P1
$P2.INIT()
I think we have to keep in mind here that there will be a *lot* of
hand-written code that needs to create PMCs from the Parrot core. I
don't want to have to use the above snippet in all my hand written
code; it adds a lot of bulk and is a huge pain.
Patrick threw out the idea of letting .Type constants refer to core
PMCs. That's a reasonable idea, I think. It lets me create them easily
and doesn't get in the way of HLL classes. And I don't think there's
any way to get those constants to work with anything but core PMCs
anyway.
How Perl 6 (or some other HLL) chooses to distinguish loading a module
written in the same HLL from loading a module written in a different HLL
is an open question. It will need some syntax. One earlier proposal
suggested separating the HLL from the rest of the name with a single
colon ('python:NLTK-Lite::Parse::LamdaCalculus').
This is included in PDD21. Perl 6 will strip off the language, split
the module name and end up with a string ("python") and an array
(['NLTK-Lite', 'Parse', 'LamdaCalculus']). It can use the string to
load the correct compiler (this is still unimplemented, by the way).
The compiler object it gets will take the array and load the
appropriate library (this is also unimplemented atm).
Perl 6 could presumably install the class into it's own HLL, which
makes instantiation easy.
--
Matt Diephouse
http://matt.diephouse.com
