From @lizmat

[14​:13​:25] <azawawi> $?FILE is not working as expected
[14​:13​:48] <azawawi> $?FILE is still refering to /home/azawawi/perl6-electron/.panda-work/1439208484_1/lib/Electron/App.pm6
[14​:14​:12] <azawawi> which panda create, installed and deleted that temp directory
[14​:14​:18] <azawawi> s/create/created
[14​:14​:45] <lizmat> m​: say $?FILE; { my $?FILE = "foo"; say $?FILE }
[14​:14​:47] <+camelia> rakudo-moar a32c14​: OUTPUT«===SORRY!=== Error while compiling /tmp/jsbZpo1Blk␤Cannot use ? twigil on my variable␤at /tmp/jsbZpo1Blk​:1␤------> say $?FILE; { my $?FILE⏏ = "foo"; say $?FILE }␤»
[14​:14​:56] <lizmat> m​: say $?FILE; { my constant $?FILE = "foo"; say $?FILE }
[14​:14​:57] <+camelia> rakudo-moar a32c14​: OUTPUT«/tmp/bMlCVlwet8␤/tmp/bMlCVlwet8␤»
[14​:15​:04] <lizmat> hmmm....
[14​:18​:32] <azawawi> lizmat​: what's the point in having a compiled $?FILE which panda totally ignores? :)
[14​:19​:11] <azawawi> my use case is that i need to find resources residing in lib/Foo/resources directory
[14​:19​:55] <lizmat> there's %RESOURCE specced for that, alas NYI
[14​:20​:00] <lizmat> hmmm....
[14​:20​:26] <lizmat> m​: say $?FILE; { my constant $?FILE = "foo"; say $?FILE } # actually feels like a bug
[14​:20​:29] <+camelia> rakudo-moar a32c14​: OUTPUT«/tmp/StJKSHy18K␤/tmp/StJKSHy18K␤»
[14​:21​:03] <lizmat> and I guess $?FILE should really be more runtime...
[14​:21​:14] <azawawi> $*FILE ?
[14​:21​:39] <azawawi> like http://perldoc.perl.org/functions/__FILE__.html
[14​:22​:42] <lizmat> yeah, but P5 doesn't have the concept of precomp, so __FILE__ is always about the file that was just opened to be parsed
[14​:33​:07] <jnthn> I'd say the bug is that constant $?FILE = ... doesn't complain the way my $?FILE = ... does.
[14​:33​:39] <jnthn> You shouldn't be able to declare $? things yourself, they're special things for the compiler to resolve. And thus they're also compile-time constants and frozen in pre-comp
[14​:34​:05] <jnthn> And no, $?FILE should not become more runtime.
[14​:34​:41] <azawawi> jnthn​: what about when panda compiles them in a temp folder .panda-work and then installs them? :)
[14​:34​:45] <lizmat> ok, I'll take that from there then
[14​:36​:09] <jnthn> azawawi​: As I understand it, it probably should be giving the files to a CompUnitRepo object to install, and leaving pre-comp to Rakudo, in which case it can copy the file in place and pre-comp it in place.
[14​:41​:24] <lizmat> jnthn​: eh, you should be able to define $?FOO yourself, no? just not redefine existing ones?
[14​:42​:39] <jnthn> lizmat​: I'm...not sure it makes a lot of sense to allow that?
[14​:43​:45] <lizmat> ok, so no "userland" $?vars then
[14​:44​:03] <lizmat> I guess that'll make it easier to be sure to prevent future collisions
[14​:44​:24] <jnthn> Right, it means we'll easily be able to introduce new ones in the future knowing only the compiler gets to set them

From @lizmat

Fixed with 571b4fab525d4ebf7e0f63c , closable with tests

On 10 Aug 2015, at 14​:48, Elizabeth Mattijsen (via RT) <perl6-bugs-followup@​perl.org> wrote​:

# New Ticket Created by Elizabeth Mattijsen
# Please include the string​: [perl #​125780]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=125780 >

[14​:13​:25] <azawawi> $?FILE is not working as expected
[14​:13​:48] <azawawi> $?FILE is still refering to /home/azawawi/perl6-electron/.panda-work/1439208484_1/lib/Electron/App.pm6
[14​:14​:12] <azawawi> which panda create, installed and deleted that temp directory
[14​:14​:18] <azawawi> s/create/created
[14​:14​:45] <lizmat> m​: say $?FILE; { my $?FILE = "foo"; say $?FILE }
[14​:14​:47] <+camelia> rakudo-moar a32c14​: OUTPUT«===SORRY!=== Error while compiling /tmp/jsbZpo1Blk␤Cannot use ? twigil on my variable␤at /tmp/jsbZpo1Blk​:1␤------> say $?FILE; { my $?FILE⏏ = "foo"; say $?FILE }␤»
[14​:14​:56] <lizmat> m​: say $?FILE; { my constant $?FILE = "foo"; say $?FILE }
[14​:14​:57] <+camelia> rakudo-moar a32c14​: OUTPUT«/tmp/bMlCVlwet8␤/tmp/bMlCVlwet8␤»
[14​:15​:04] <lizmat> hmmm....
[14​:18​:32] <azawawi> lizmat​: what's the point in having a compiled $?FILE which panda totally ignores? :)
[14​:19​:11] <azawawi> my use case is that i need to find resources residing in lib/Foo/resources directory
[14​:19​:55] <lizmat> there's %RESOURCE specced for that, alas NYI
[14​:20​:00] <lizmat> hmmm....
[14​:20​:26] <lizmat> m​: say $?FILE; { my constant $?FILE = "foo"; say $?FILE } # actually feels like a bug
[14​:20​:29] <+camelia> rakudo-moar a32c14​: OUTPUT«/tmp/StJKSHy18K␤/tmp/StJKSHy18K␤»
[14​:21​:03] <lizmat> and I guess $?FILE should really be more runtime...
[14​:21​:14] <azawawi> $*FILE ?
[14​:21​:39] <azawawi> like http://perldoc.perl.org/functions/__FILE__.html
[14​:22​:42] <lizmat> yeah, but P5 doesn't have the concept of precomp, so __FILE__ is always about the file that was just opened to be parsed
[14​:33​:07] <jnthn> I'd say the bug is that constant $?FILE = ... doesn't complain the way my $?FILE = ... does.
[14​:33​:39] <jnthn> You shouldn't be able to declare $? things yourself, they're special things for the compiler to resolve. And thus they're also compile-time constants and frozen in pre-comp
[14​:34​:05] <jnthn> And no, $?FILE should not become more runtime.
[14​:34​:41] <azawawi> jnthn​: what about when panda compiles them in a temp folder .panda-work and then installs them? :)
[14​:34​:45] <lizmat> ok, I'll take that from there then
[14​:36​:09] <jnthn> azawawi​: As I understand it, it probably should be giving the files to a CompUnitRepo object to install, and leaving pre-comp to Rakudo, in which case it can copy the file in place and pre-comp it in place.
[14​:41​:24] <lizmat> jnthn​: eh, you should be able to define $?FOO yourself, no? just not redefine existing ones?
[14​:42​:39] <jnthn> lizmat​: I'm...not sure it makes a lot of sense to allow that?
[14​:43​:45] <lizmat> ok, so no "userland" $?vars then
[14​:44​:03] <lizmat> I guess that'll make it easier to be sure to prevent future collisions
[14​:44​:24] <jnthn> Right, it means we'll easily be able to introduce new ones in the future knowing only the compiler gets to set them

From @usev6

After some discussion it was decided to let that fail with X​::Comp​::NYI for now​:

$ perl6 -e 'say $?FILE; { my constant $?FILE = "foo"; say $?FILE }'
===SORRY!=== Error while compiling -e
Constants with a '?' twigil not yet implemented. Sorry.
at -e​:1
------> say $?FILE; { my constant $?FILE = "foo"⏏; say $?FILE }

See the discussion at #perl6 from 2015-08-17 (around http://irclog.perlgeek.de/perl6/2015-08-17#i_11069350; search for af61bb2, 82ea784 and f58a726 to get more background).

I added a test to S32-exceptions/misc.t with commit Raku/roast@a5831ca942.

I'm closing this ticket as 'resolved'.

@usev6 - Status changed from 'new' to 'resolved'