Module naming scheme

I have been trying to create an interpreter for DP6 in D, and one of the annoying things I have found, is that you can't have a module with the name io, and one with the name io.file. There is a good reason for it, since if you have a class with the name file, in the module io that would cause name collisions.

So what I'm planning fo DP6 is that the module heirarchy will use double colons like Perl. Then io and io::file couldn't possibly have name collisions, because the class file in the module io will be addressed by io.file.

I also like the way you can switch modules in Perl. So I am conidering allowing a module switch packages. It really depends on whether that could cause a bunch of headache when writing a compiler.

Struct will have members

I like the idea of having structs that act in a similar way to that of normal objects, similar to the D way.

struct Test{
int $a;
sub a( $this, int $new ){
$a = $new;
}
}

Test test;
# following are equivalent
test.a(5);
test.a = 5;

The way that Perl6 handles public/private data, will also be included.

class Test{
$a is readonly;
$b is rw;
}

Perl6 style macros

There will Perl6 syle macros to allow the language to be modified to suit the users needs.

This would require that at least some of the code has to be runnable before it gets completely compiled. I would suspect that the compile time code will run at a much lower speed. I think that this would allow D style version( ) statements to be able to be included, without hard coding it into the parser.

I find that there are times were I want to change how the program is parsed, so that I can do the same thing to different types of data, without retypeing it. D does to some extent, provide these facilities, but I want to take it farther.

Garbage Collector

All Modules will be able to turn on or off the Garbage Collector for itself, and be able to suspend the Garbage collector on behalf any module, or even globally.

Modules will also be able to select which Garbage Collector gets used for objects that it generates.

The Garbage Collector will be turned on by default for every package, but no Garbage Collector in particular will be selected.
use GC;
use GC 'any';

If the program selects a particular GC to use, it will be used by any modules that doesn't specify which GC it will use.
use GC 'system';
use GC GC::system;

A module will be able to turn off all GC's, for itself. The reason for this is that a programmer could then write a GC as a module.
no GC;
Doing a no GC; inside of a block will turn it off for that block

All GC's will be required to handle self referencial data structures correctly.

Whenever the GC is turned off the compiler will make sure an object is deleted when the block is exited. The programmer may put a delete in the block so that the object gets deleted early. If the programmer is giving a reference to some other subroutine, there will be some way of preventing the object from being deleted, how this will work I'm not sure.

Note: the way I have designed the way GC's are used there will have to be some way of using an object with more than one GC at a time, again I am unsure of how this will be accomplished, but I am confident that it can be done.