A few meta-comments:

sub import($pkg : ARRAY $export=undef, ARRAY $ok=undef, HASH $tags=und
+ef) {
[download]

Now, I'm not sure what the undef if for. I think this is to establish a default, which means that this is (I think) a typo. If so, it should read:

ARRAY $export //= undef
[download]

That's right (as of Larry's last communication with me on the subject).

Now, as for how this all fits together, I'm not sure. The colon operator appears to be explained in Exegesis 3, page 6, under the heading "The ∑ of all our fears". I read and read and reread that section, but couldn't figure out what that meant in relation to the arg list in import(). Could someone please enlighten me?

No. But I'll try and answer your question. ;-)

A colon in the parameter list of a subroutine means that a colon should appear in the same spot in the argument list with which the sub is invoked.

Typically the colon will be after the first argument, which will then be treated as the "invocant" of the subroutine. But it may be possible to put a colon (or even several of them) at other points in the param list as well. In such cases, arguments appearing after the colon will be thought of as adverbs modifying the call, though it's not yet clear whether there will be language level consequences of that convention.

    my $from_pkg=caller.package;
[download]

Okay, that's pretty nifty. package is an attribute of caller (or is it a method that returns a value?).

Yes. ;-)

In Perl 6 there is much less difference between an attribute and a method. Most attributes like this will have lvalue public accessor methods.

This is much easier to read then caller(0). I wonder, though, if we can adjust this to allow us to export to a lexical scope. There's been a fair amount of talk about a MY pseudo-package and having this accessible to caller. This could allow us to export something to a limited scope and not screw with the caller's symbol table! The following code is completely speculative, of course.

    my $from_pag = caller.MY.package;
[download]

Something like this is quite likely. Though it would only work at compile-time.

The only thing I'm wondering about is whether or not beginning a function name with an ampersand and leaving off the parens will result in @_ being passed through (and aliased).

No. That behaviour is gone from Perl 6.

&subname is simply the fully-sigilled name of that subroutine. As an lvalue of a binding operator, it specifies the subroutine to be bound. As a scalar rvalue, it produces a reference to the subroutine in question.

sub myimport($exp_from : *@symbols=() : *@options=()) {
[download]

Aack! What the heck is that? The asterisk flattens the the arguments to a list and allows the array to slurp up the rest of the arguments, but I don't get this. Once again, any explanation would be helpful.

This is an example of the multi-colon syntax I mentioned above. The code means:

sub myimport($exp_from         # expect a scalar as arg 1
             :                 # then expect a colon
             *@symbols=()      # then flatten any args
             :                 # until another colon
             *@options=()      # then flatten any more args
            ) {
[download]

BTW, the default values again need the operator (//=) here, rather than =. They're also redundant here (except as self-documentation, of course).

Now, as I understand it, dereferencing will be a DWIM sort of thing. Thus, the type sigils on the right are not necessary.

    if(defined $export) {
        @Exporter::From::EXPORT = $export;
    }

    if(defined $ok) {
        @Exporter::From::EXPORT_OK = $ok;
    }

    if(defined $tags) {
        %Exporter::From::EXPORT_TAGS = $tags;
    }
}
[download]

There's no need to dereference anymore (except in unusual cases where the code is ambiguous) as Perl6 will do it for us.

That's correct. The only issue is whether the first two cases above are ambiguous, since they already have a meaning ("set the rvalue array to a single element which is a copy of the lvalue") in Perl 5.

Personally, I think that assignment of a scalar to an array will dwimically dereference an lvalue that's an array reference, but Larry will have to rule on that.