Skip Menu |
Report information
Id: 131528
Status: open
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: cpan [at] zoffix.com
Cc:
AdminCc:

Severity: (no value)
Tag: (no value)
Platform: (no value)
Patch Status: (no value)
VM: (no value)



Subject: [PRECOMP] Issues when sub itself instead of its "dispatcher" used in sub EXPORT
From what I understand subs—even `only` subs—have another Sub playing the role of a dispatcher or whatever: m: sub foo {}.WHERE.say; &foo.WHERE.say rakudo-moar dbd0f8: OUTPUT: «139686084622776␤139686084191728␤» And it seems when the sub itself, instead of this "dispatcher", is used in sub EXPORT in a precompiled module that's used by another precompiled module, some wires get crossed over and the sub cannot be called: m: sub foo {}.WHERE.say; &foo.WHERE.say rakudo-moar dbd0f8: OUTPUT: «139686084622776␤139686084191728␤» $ cat Foo.pm6 sub EXPORT { Map.new: '&foo' => sub foo { say 42 } } $ cat Bar.pm6 use Foo; foo $ perl6 -I. -MFoo -e 'foo' 42 $ perl6 -I. -MBar -e '' ===SORRY!=== Cannot invoke this object (REPR: Null; VMNull) $ Doing any of the following fixes the above bug: - adding `no precompilation` to Foo.pm6 - adding `no precompilation` to Bar.pm6 - instead of using the sub directly, defining it separately and using `&foo` as value in the Map
Date: Thu, 08 Jun 2017 16:15:29 +0000
From: Lloyd Fournier <lloyd.fourn [...] gmail.com>
To: perl6-compiler [...] perl.org, bugs-bitbucket [...] rt.perl.org
Subject: Re: [perl #131528] [PRECOMP] Issues when sub itself instead of its "dispatcher" used in sub EXPORT
Download (untitled) / with headers
text/plain 1.7k
I think this is just another example of the compile time closures problem since EXPORT runs at compile time in during the loading module's compilation.


For an example in my own code:


I can't put that sub definition in the constant assignment because it runs at compile time.

On Thu, Jun 8, 2017 at 2:31 AM Zoffix Znet <perl6-bugs-followup@perl.org> wrote:
Show quoted text
# New Ticket Created by  Zoffix Znet
# Please include the string:  [perl #131528]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/Ticket/Display.html?id=131528 >


From what I understand subs—even `only` subs—have another Sub playing the role of a dispatcher or whatever:

m: sub foo {}.WHERE.say; &foo.WHERE.say
rakudo-moar dbd0f8: OUTPUT: «139686084622776␤139686084191728␤»

And it seems when the sub itself, instead of this "dispatcher", is used in sub EXPORT in a precompiled
module that's used by another precompiled module, some wires get crossed over and the sub cannot be called:

    m: sub foo {}.WHERE.say; &foo.WHERE.say
    rakudo-moar dbd0f8: OUTPUT: «139686084622776␤139686084191728␤»


    $ cat Foo.pm6
    sub EXPORT {
        Map.new: '&foo' => sub foo { say 42 }
    }

    $ cat Bar.pm6
    use Foo;
    foo

    $ perl6 -I. -MFoo -e 'foo'
    42

    $ perl6 -I. -MBar -e ''
    ===SORRY!===
    Cannot invoke this object (REPR: Null; VMNull)
    $

Doing any of the following fixes the above bug:

- adding `no precompilation` to Foo.pm6
- adding `no precompilation` to Bar.pm6
- instead of using the sub directly, defining it separately and using `&foo` as value in the Map


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org