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

UNIT::EXPORT and Foo::EXPORT are no longer comparable (Foo::EXPORT === UNIT::EXPORT) #5932

Open
p6rt opened this issue Dec 29, 2016 · 4 comments
Open
Labels

Comments

@p6rt
Copy link

@p6rt p6rt commented Dec 29, 2016

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

Searchable as RT130435$

@p6rt

This comment has been minimized.

Copy link
Author

@p6rt p6rt commented Dec 29, 2016

From @AlexDaniel

Code​:
unit module Foo; sub foo() is export {}; say Foo​::EXPORT === UNIT​::EXPORT # unit makes the declared package the current UNIT

Result (2016.04)​:
True

Result (HEAD)​:
False

Bisectable is pointing to rakudo/rakudo@fe2be65

@p6rt

This comment has been minimized.

Copy link
Author

@p6rt p6rt commented Aug 15, 2017

From @skids

On Wed, 28 Dec 2016 19​:46​:01 -0800, alex.jakimenko@​gmail.com wrote​:

Code​:
unit module Foo; sub foo() is export {}; say Foo​::EXPORT ===
UNIT​::EXPORT # unit makes the declared package the current UNIT

Result (2016.04)​:
True

Result (HEAD)​:
False

Bisectable is pointing to
rakudo/rakudo@fe2be65

Since that commit, rakudo/rakudo@4d85cde
also would have regressed this behavior if it had not already been regressed, and there have been
other commits since that may also.

The bug which 4d85cde9 was trying to address, #​128931, pointed out that any two types with the same
name had the same .WHICH.

It is proper that we should have different .WHICH's on different type objects, even if they have
the same name. However, it appears that in the case of UNIT​:: and perhaps some other/future
PseudoStash aliases, EXPORT may be being treated as a value type and copied around... (EXPORT is
immutable outside of COMPILING and metaprogramming APIs)​:

$ perl6 -e 'unit module Foo; use nqp; sub g is export { }; nqp​::say(nqp​::eqaddr(Foo​::EXPORT, UNIT​::EXPORT))'
0

...that will either have to be fixed, or worked around.

@p6rt

This comment has been minimized.

Copy link
Author

@p6rt p6rt commented Aug 15, 2017

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

@p6rt

This comment has been minimized.

Copy link
Author

@p6rt p6rt commented Aug 19, 2017

From @skids

On Wed, 28 Dec 2016 19​:46​:01 -0800, alex.jakimenko@​gmail.com wrote​:

Code​:
unit module Foo; sub foo() is export {}; say Foo​::EXPORT ===
UNIT​::EXPORT # unit makes the declared package the current UNIT

Result (2016.04)​:
True

Result (HEAD)​:
False

Bisectable is pointing to
rakudo/rakudo@fe2be65

OK, I looked into this some more, and I don't think it is a bug.

"unit module" is documented as such​:
in S02​: unit # like our, but introduces a compilation-unit scoped name
in S11​: unit module Foo; # rest of scope is in module Foo

None of that says UNIT and unit module Foo will be the same package, just that
everything in the rest of the file will be lexically inside Foo. Note that
the UNIT/SETTING/CORE packages are lexical scopes and your program is the
next *block* below UNIT, whereas the GLOBAL "package scope" is what is above
your *package* ... so there is an apples and oranges difference between
"Foo​::" and "UNIT​::".

The description of the EXPORT and UNIT​::EXPORT classes are as such in S11​:

"Every compunit has a C<UNIT> package, which gets a lexically scoped C<EXPORT>
package automatically. Declarations marked as C<is export> are bound into
it, with their tagsets as inner packages.
...
Exports contained within a module will also be bound into an our-scoped
C<EXPORT> package nested in the module, again with the tagsets forming
inner packages. This is so the C<import> keyword can be used with a package
...
Inner packages automatically add their export list to packages in all their
outer scopes (including UNIT)"

...note I think there is a typo in S11 where it says​:

the lexical C<IMPORT> package in C<UNIT>, on the other
hand, is the only thing that is considered by C<use> for importing.

...in that IMPORT should be EXPORT.

I don't see anything in roast that tests that the two EXPORTs are ===,
so this behavior was never promised, it just "worked" by accident
until other changes disrupted it.

Now the question is, what was the use case of comparing the two EXPORT
stashes, and/or what behavior results from them being different which
is problematic? I'd consult IRC or the mailing list to figure out a
different way to do whatever this was intended to do.

Keeping this open so the spec typo may be verified by second opinion and
fixed, but then we should close/reject this ticket.

@p6rt p6rt added the regression label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.