Re: Re: classnames and HLL namespaces -- help!
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
Re: Re: classnames and HLL namespaces -- help!
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 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
Re: Re: classnames and HLL namespaces -- help!
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
