Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EXPORT ignored when unit module/package is used #5063

Open
p6rt opened this issue Jan 18, 2016 · 11 comments
Open

EXPORT ignored when unit module/package is used #5063

p6rt opened this issue Jan 18, 2016 · 11 comments

Comments

@p6rt
Copy link

@p6rt p6rt commented Jan 18, 2016

Migrated from rt.perl.org#127305 (status was 'open')

Searchable as RT127305$

@p6rt

This comment has been minimized.

Copy link
Author

@p6rt p6rt commented Jan 18, 2016

From @gfldex

# https://gist.github.com/b0d44595e0d3b314a09d

# Module.pm6
unit module Module;

sub EXPORT ($var) {
  { foo => sub () {} }
}

# use-module.p6

use v6;
use lib '.';
use Module 42;

# OUTPUT​:
# Error while importing from 'Module'​:
# no EXPORT sub, but you provided positional argument in the 'use' statement
# at /home/dex/projekte/perl6/rakudobug/EXPORT+unit-package/use-module.p6​:3
# ------> use Module 42⏏;

# Package.pm6

unit package Package;

sub EXPORT ($var) {
  { foo => sub () {} }
}

# use-package.p6

use v6;
use lib '.';
use Package 42;

# OUTPUT​:
# Error while importing from 'Package'​:
# no EXPORT sub, but you provided positional argument in the 'use' statement
# at /home/dex/projekte/perl6/rakudobug/EXPORT+unit-package/use-package.p6​:3
# ------> use Package 42⏏;

# expected​: either complain about unit and EXPORT in the same file or
# make it work

@p6rt

This comment has been minimized.

Copy link
Author

@p6rt p6rt commented Jan 18, 2016

From @jnthn

On Sun Jan 17 22​:29​:57 2016, gfldex wrote​:

# https://gist.github.com/b0d44595e0d3b314a09d

# Module.pm6
unit module Module;

sub EXPORT ($var) {
{ foo => sub () {} }
}

# use-module.p6

use v6;
use lib '.';
use Module 42;

# OUTPUT​:
# Error while importing from 'Module'​:
# no EXPORT sub, but you provided positional argument in the 'use'
statement
# at /home/dex/projekte/perl6/rakudobug/EXPORT+unit-package/use-
module.p6​:3
# ------> use Module 42⏏;

# Package.pm6

unit package Package;

sub EXPORT ($var) {
{ foo => sub () {} }
}

# use-package.p6

use v6;
use lib '.';
use Package 42;

# OUTPUT​:
# Error while importing from 'Package'​:
# no EXPORT sub, but you provided positional argument in the 'use'
statement
# at /home/dex/projekte/perl6/rakudobug/EXPORT+unit-package/use-
package.p6​:3
# ------> use Package 42⏏;

# expected​: either complain about unit and EXPORT in the same file or
# make it work

&EXPORT must be in the outermost lexical scope of the compilation unit. Which...uh...it appears it should be here! I suspect the compiler is sneaking a secret extra scope in as a result of the unit declaration. Can we fix that? Yes for module/class/grammar. But for roles, not really as they're generic and the parameter has to go somewhere. But that makes a weird discontinuity. Hmmm. :-)

@p6rt

This comment has been minimized.

Copy link
Author

@p6rt p6rt commented Jan 18, 2016

The RT System itself - Status changed from 'new' to 'open'

@p6rt

This comment has been minimized.

Copy link
Author

@p6rt p6rt commented Jan 19, 2016

From @LLFourn

I am going to sneak in a docs discussion into this ticket with regards to
EXPORT some relevant parties are here.

http://docs.perl6.org/language/modules#EXPORT

I mentioned when I wrote it​:
"Note, EXPORT can't be declared inside a package because presently rakudo
(2015.09) seems to treat EXPORT as part of the compunit rather than the
package."

Of course, happy for that to change. With my more nuanced understanding of
this I could re-write this as​:

"for EXPORT to be called it must be defined at UNIT​::&EXPORT. Therefore it
cannot be defined inside a package".

Maybe if a package is declared as UNIT, all its lexical symbols could be
inserted both into the package and UNIT.

gfldex, I see you've edited the second EXPORT example, but to me it's made
it much less clear what's going on. I see where you are going, trying to
show that the power of :​:T type captures can still be used in EXPORT, but I
think we should leave that up to the imagination of the user. EXPORT is
just a sub after all so those features are naturally there. Perhaps that
example could go into a "cookbook" type thing.

Thanks!

On Tue, Jan 19, 2016 at 5​:03 AM jnthn@​jnthn.net via RT <
perl6-bugs-followup@​perl.org> wrote​:

On Sun Jan 17 22​:29​:57 2016, gfldex wrote​:

# https://gist.github.com/b0d44595e0d3b314a09d

# Module.pm6
unit module Module;

sub EXPORT ($var) {
{ foo => sub () {} }
}

# use-module.p6

use v6;
use lib '.';
use Module 42;

# OUTPUT​:
# Error while importing from 'Module'​:
# no EXPORT sub, but you provided positional argument in the 'use'
statement
# at /home/dex/projekte/perl6/rakudobug/EXPORT+unit-package/use-
module.p6​:3
# ------> use Module 42⏏;

# Package.pm6

unit package Package;

sub EXPORT ($var) {
{ foo => sub () {} }
}

# use-package.p6

use v6;
use lib '.';
use Package 42;

# OUTPUT​:
# Error while importing from 'Package'​:
# no EXPORT sub, but you provided positional argument in the 'use'
statement
# at /home/dex/projekte/perl6/rakudobug/EXPORT+unit-package/use-
package.p6​:3
# ------> use Package 42⏏;

# expected​: either complain about unit and EXPORT in the same file or
# make it work

&EXPORT must be in the outermost lexical scope of the compilation unit.
Which...uh...it appears it should be here! I suspect the compiler is
sneaking a secret extra scope in as a result of the unit declaration. Can
we fix that? Yes for module/class/grammar. But for roles, not really as
they're generic and the parameter has to go somewhere. But that makes a
weird discontinuity. Hmmm. :-)

@p6rt

This comment has been minimized.

Copy link
Author

@p6rt p6rt commented Jan 20, 2016

From @gfldex

On Mon, 18 Jan 2016, Lloyd Fournier via RT wrote​:

gfldex, I see you've edited the second EXPORT example, but to me it's made
it much less clear what's going on.

I'm not happy with that example myself and intend to change it.

I see where you are going, trying to show that the power of :​:T type
captures can still be used in EXPORT, but I think we should leave that
up to the imagination of the user.

I do not agree with the notion "Let's not tell them!". The whole point of
a documentation is to save the person who reads it time. This is one bug
report out of 5 related to EXPORT and/or type captures. It took me about 6
hours to find all the bits that work/don't work and led to the following
blog post [1]. Let's assume that in the course of the next year alone 100
brave souls (likely a low figure) read that section of the doc. That's 600
manhours that could be spend more productive. The whole point of Perl 6 is
to let programmers be more lazy. Productive! Productive I mean!

[1] https://gfldex.wordpress.com/

@p6rt

This comment has been minimized.

Copy link
Author

@p6rt p6rt commented Jan 23, 2016

From @LLFourn

gfldex++ for blogging.

My basic feeling about documentation is that it should​:

1. Explain the construct, it's purpose and behaviour.
2. Give code examples that explain one thing and do it well.

The original example was there to explain that you would not get DEFAULT
exports if you pass a positional in. After it was changed it no longer
compiled, and no longer was clear to me what it was showing.

Though, I agree with you that type captures in EXPORT are worth showing,
and since we don't have a cookbook thing yet, I put them into a second
example which aims to show them in the most minimal way possible.

Raku/doc@5dbb3a1

Feel free to make changes as always. And thanks for your contributions!

I suppose we should leave this ticket for the bug now ;)

On Thu, Jan 21, 2016 at 12​:59 AM Wenzel P. P. Peppmeyer <
wenzel.peppmeyer@​gmx.de> wrote​:

On Mon, 18 Jan 2016, Lloyd Fournier via RT wrote​:

gfldex, I see you've edited the second EXPORT example, but to me it's
made
it much less clear what's going on.

I'm not happy with that example myself and intend to change it.

I see where you are going, trying to show that the power of :​:T type
captures can still be used in EXPORT, but I think we should leave that
up to the imagination of the user.

I do not agree with the notion "Let's not tell them!". The whole point of
a documentation is to save the person who reads it time. This is one bug
report out of 5 related to EXPORT and/or type captures. It took me about 6
hours to find all the bits that work/don't work and led to the following
blog post [1]. Let's assume that in the course of the next year alone 100
brave souls (likely a low figure) read that section of the doc. That's 600
manhours that could be spend more productive. The whole point of Perl 6 is
to let programmers be more lazy. Productive! Productive I mean!

[1] https://gfldex.wordpress.com/

@p6rt

This comment has been minimized.

Copy link
Author

@p6rt p6rt commented Oct 25, 2016

From @tbrowder

In a conversation about this issue on IRC channel #perl6 on 25 Oct 2016 starting at approx 06​:24, module authors and users express concern about modules polluting the user's namespace.

Several main desires IMHO​:

User​:

1. Selective import by object name(s) or tag(s).

2. Selective import by excluding object name(s) or tag(s) [perlpilot].

Author​:

1. Tagging or otherwise marking subs to enable the user desires above.

2. Enable multiple export tags to better organize export categories.

1 similar comment
@p6rt

This comment has been minimized.

Copy link
Author

@p6rt p6rt commented Oct 25, 2016

From @tbrowder

In a conversation about this issue on IRC channel #perl6 on 25 Oct 2016 starting at approx 06​:24, module authors and users express concern about modules polluting the user's namespace.

Several main desires IMHO​:

User​:

1. Selective import by object name(s) or tag(s).

2. Selective import by excluding object name(s) or tag(s) [perlpilot].

Author​:

1. Tagging or otherwise marking subs to enable the user desires above.

2. Enable multiple export tags to better organize export categories.

@p6rt

This comment has been minimized.

Copy link
Author

@p6rt p6rt commented Oct 25, 2016

From @tbrowder

On Tue Oct 25 06​:07​:15 2016, tbrowder wrote​:

In a conversation about this issue on IRC channel #perl6 on 25 Oct
2016 starting at approx 06​:24,

The URL to the thread start is​:

  https://irclog.perlgeek.de/perl6/2016-10-25#i_13461499

@p6rt

This comment has been minimized.

Copy link
Author

@p6rt p6rt commented Oct 25, 2016

From @tbrowder

On Tue Oct 25 06​:07​:15 2016, tbrowder wrote​:

In a conversation about this issue on IRC channel #perl6 on 25 Oct
2016 starting at approx 06​:24, module authors and users express
concern about modules polluting the user's namespace.

Several main desires IMHO​:

User​:

1. Selective import by object name(s) or tag(s).

Note that selective import by tag is possible now if the author tags each subroutine export trait with the sub name or an alias or both.

2. Selective import by excluding object name(s) or tag(s) [perlpilot].

Author​:

1. Tagging or otherwise marking subs to enable the user desires above.

This is possible now for import selection, but not import by exclusion.

2. Enable multiple export tags to better organize export categories.

Disregard, this is possible now.

@p6rt

This comment has been minimized.

Copy link
Author

@p6rt p6rt commented Apr 26, 2017

From @skids

On Tue, 25 Oct 2016 08​:22​:19 -0700, tbrowder wrote​:

2. Enable multiple export tags to better organize export categories.

Disregard, this is possible now.

Well, mostly. Note you still cannot export different values for the same symbol
based on a tag (i.e. without sub EXPORT)

$ perl6 -e 'unit module foo; my class A { my class A is export(​:foo1) { }; }; my class B { my class A is export(​:foo2) { } }'
===SORRY!=== Error while compiling -e
A symbol 'A' has already been exported
at -e​:1
$ perl6 -e 'module foo { my class A { my class A is export(​:foo1) { }; }; }; module bar { my class B { my class A is export(​:foo2) { } }};'
===SORRY!=== Error while compiling -e
A symbol 'A' has already been exported
at -e​:1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.