One more approach for EXPORT problems.

[vrurg]

What Is Wrong

The problem with EXPORT is best demonstrated by this example gist where running use.p6 results in:

Scalar
===SORRY!===
P6opaque: no such attribute '@!dispatchees' on type Routine in a Scalar when trying to get a value

The cause lies in the fact that symbols are exported using Hashes which containerize their values. By the moment mod3 is imported there is &trait_mod:<is> installed in use.p6 which is Scalar containing the dispatcher Sub, as follows from the error message the output of BEGIN block.

While I managed to partially address this issue with rakudo/rakudo#3016 but that PR is still more of a palliative but not the cure. After some discussion (though I don't remember exactly where it took place) I was convinced that deconting of &-sigiled symbols is not needed and even harmful. An example of why is it so would be:

sub foo is export { }
our &foo_alias is export = &foo;

Where &foo_alias is actually a writable scalar. Deconting it would break a code in a module consuming code:

&foo_alias = &my_foo;  # cannot change a read-only value

Proposed solution

Considering that the following use of EXPORT routine is now commonplace:

multi EXPORT {
    %(
        My::Other::Module::EXPORT::DEFAULT::, 
        '&foo' => &bar
    )
}

and by taking into account that containerization of Hash values is done on purpose and is a key part of the language definition, I see the following as a solution with the least need amount of changes to both the core and the user land while improving overall DWIM logic:

1. Stash behavior changes in a way that assigning to a key doesn't containerize the value. Basically, assignment and binding become the same. I.e.:

   my %h is Stash = '&foo' => &foo;
   say %h<&foo>.VAR.^name; # Sub; now it'd be Scalar
   

2. Stash has to become the de-facto standard of EXPORT return value. I would even make it a warning if Hash is returned.

3. Because

   multi EXPORT { 
       Stash.new: My::Other::Module::EXPORT::DEFAULT:: 
   }
   

   is somewhat cumbersome, I propose a new operator ( ):: Which follows the common logic of :: used to access symbol tables. Though in this case it'd be used to create one:

   multi EXPORT {
       ( My::Other::Module::EXPORT::DEFAULT:: )::
   }
   

   A sample implementation of the operator can be found in the same gist in file mod3.pm6.

With this proposal there will be no more need to guess if &foo is the actual routine or a variable aliasing a routine.

Affected Cases

I suspect that a number of 'Cannot invoke this object (REPR: Null; VMNull)' or 'No such method 'CALL-ME' for invocant' issues could be caused the this problem of EXPORT. Not necessarily by re-exporting via &EXPORT but could be indirectly caused by manipulations with a Stash object.

[vrurg]

PR rakudo/rakudo#3076 implements this proposal. Passes all tests. No tests for the PR itself are added yet as I'm not certain if this proposal would be accepted.

With the above PR the example in gist works as expected if Stash.new or ():: operator is used in EXPORT. It also fixes a problem with my internal project which uses Red framework and was suffering from 'No such method 'CALL-ME' for invocant' error.

[lizmat]

The BIG problem with rakudo/rakudo#3081 is that it makes Map to no longer be a value type, but it becomes an object type.

[vrurg]

@lizmat proposed and implemented with rakudo/rakudo#3081 non-decontainerizing Map which actually provides the ultimate solution to the export problem. If no unwanted side effects would pop up then this problem could be closed later.

[vrurg]

Closed via rakudo/rakudo#3081.