Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Namespaces in IMCC

2 views
Skip to first unread message

Dan Sugalski

unread,
Mar 9, 2004, 12:19:08 PM3/9/04
to perl6-i...@perl.org
While we still need to nail down the final bits of namespace stuff,
I'm running into the need for it in IMCC code, so its time to finally
deal with it.

I don't really care what the syntax looks like, so I'm proposing:

.namespace [foo; bar; baz]

as a way to set the current namespace for subs to foo::bar::baz. Any
sub defined from that point on in the current source file will go
into that namespace, unless the namespace is explicitly changed later
on.

We'll deal with namespaces shortly, after nailing down the last bits
of the current object scheme's inefficiencies.
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk

Leopold Toetsch

unread,
Mar 9, 2004, 3:00:50 PM3/9/04
to Dan Sugalski, perl6-i...@perl.org
Dan Sugalski <d...@sidhe.org> wrote:
> While we still need to nail down the final bits of namespace stuff,
> I'm running into the need for it in IMCC code, so its time to finally
> deal with it.

> I don't really care what the syntax looks like, so I'm proposing:

> .namespace [foo; bar; baz]

While I see that's necessary it's not that simple ...

> as a way to set the current namespace for subs to foo::bar::baz. Any
> sub defined from that point on in the current source file will go
> into that namespace, unless the namespace is explicitly changed later
> on.

... because, what does it mean: "Any sub [..] will go into that
namespace"?

C<.namespace> is currently in use for defining kind of scoped names, but
that wouldn't conflict with above bracket syntax.

Anway, whe should really define, what are the duties of the PIR
assembler towards variable names, name mangling, lexical scopes,
namespaces, globals, and all that related stuff. We need it. It's not
defined.

> We'll deal with namespaces shortly, after nailing down the last bits
> of the current object scheme's inefficiencies.

Yes please, ++detailed_mode :)

leo

Dan Sugalski

unread,
Mar 10, 2004, 10:22:52 AM3/10/04
to l...@toetsch.at, perl6-i...@perl.org
At 9:00 PM +0100 3/9/04, Leopold Toetsch wrote:
>Dan Sugalski <d...@sidhe.org> wrote:
>> While we still need to nail down the final bits of namespace stuff,
>> I'm running into the need for it in IMCC code, so its time to finally
>> deal with it.
>
>> I don't really care what the syntax looks like, so I'm proposing:
>
>> .namespace [foo; bar; baz]
>
>While I see that's necessary it's not that simple ...

Oh, sure it is. :)

> > as a way to set the current namespace for subs to foo::bar::baz. Any
>> sub defined from that point on in the current source file will go
>> into that namespace, unless the namespace is explicitly changed later
>> on.
>
>... because, what does it mean: "Any sub [..] will go into that
>namespace"?

Well, from what I've seen so far, you're slamming all subs into the
base namespace, so that if I have IMCC code that does:

.pcc_sub foo
.end

there's a foo entry in the base namespace. Which is fine. What I want
the .namespace (or whatever) thing to do is alter the default
namespace that's used.

>Anway, whe should really define, what are the duties of the PIR
>assembler towards variable names, name mangling, lexical scopes,
>namespaces, globals, and all that related stuff. We need it. It's not
>defined.

Fair enough. Generally I don't want the PASM/PIR assemblers to do a
whole lot, since I'm not sure it's a good idea. I was going to put
this off a bit longer, but I see it's past time to do that.

This also gets into the decisions of what metadata goes into the
bytecode files and what the bytecode loader is responsible for doing,
unfortunately. So we get to revisit bytecode and metadata too.
Wheee....

Leopold Toetsch

unread,
Mar 10, 2004, 12:58:55 PM3/10/04
to Dan Sugalski, perl6-i...@perl.org
Dan Sugalski <d...@sidhe.org> wrote:
> At 9:00 PM +0100 3/9/04, Leopold Toetsch wrote:

>>While I see that's necessary it's not that simple ...

> Oh, sure it is. :)

> Well, from what I've seen so far, you're slamming all subs into the


> base namespace, so that if I have IMCC code that does:

> .pcc_sub foo
> .end

> there's a foo entry in the base namespace. Which is fine. What I want
> the .namespace (or whatever) thing to do is alter the default
> namespace that's used.

Silly me. Of course.

Should be ratber simple to implement. Tomorrow.

leo

Leopold Toetsch

unread,
Mar 11, 2004, 8:14:40 AM3/11/04
to Dan Sugalski, perl6-i...@perl.org
Dan Sugalski <d...@sidhe.org> wrote:
> While we still need to nail down the final bits of namespace stuff,
> I'm running into the need for it in IMCC code, so its time to finally
> deal with it.

> I don't really care what the syntax looks like, so I'm proposing:

> .namespace [foo; bar; baz]

Done a bit:

.namespace [ "Foo" ]
.namespace [ "Foo"; "Bar" ]

the latter is only in the parser currently (no deepere nesting yet).

Do we want bare words too?

leo

Dan Sugalski

unread,
Mar 11, 2004, 8:42:41 AM3/11/04
to l...@toetsch.at, perl6-i...@perl.org

Cool.

>Do we want bare words too?

No, I don't think so. I want to move away from bare words for
namespaces as soon as we can--what's in now's just a hack/stopgap to
get things moving.

Leopold Toetsch

unread,
Mar 11, 2004, 10:11:54 AM3/11/04
to Dan Sugalski, perl6-i...@perl.org
Dan Sugalski <d...@sidhe.org> wrote:
> While we still need to nail down the final bits of namespace stuff,
> I'm running into the need for it in IMCC code, so its time to finally
> deal with it.

> I don't really care what the syntax looks like, so I'm proposing:

> .namespace [foo; bar; baz]

> as a way to set the current namespace for subs to foo::bar::baz.

I have now implemented the nested namespace too:

.namespace ["Foo";"Bar"]
.pcc_sub __init:

The label gets mangled to:

_Foo::Bar::__init:

and the nested namespaces are (hopefully) built correctly. But I can't
test it. Nested namespaces aren't search yet.

leo

0 new messages