I've been considering how to inject compile-time values ($?VAR) into
Rakudo.
I was thinking about how to implement $?LINE and came up with two
ways to do it: on the fly and post processing.
On the fly would require some significant work in PGE, I think, to
keep the line count correct in the face of backtracking. However,
this may already be necessary down the road for proper line numbers
in error messages for code mapped from an HLL to a lower level syntax.
Post-processing on the other hand would require me to keep an
actions.pm 'our' variable of whether we found a $?LINE or not. Only
if so, then in TOP we walk the parse tree counting newlines and
replacing PAST::Var(:name('$?LINE')) with PAST::Val(:value
($linecount)). That way, we'd encounter no performance hit if there
were no line number requests.
The former seems like the right general solution for the long term,
but the latter seems doable today. Thoughts?
Other compile-time variables like $?OS and $?FILE seem easier to
implement because they require a lot less context. I think $?OS is
just the NQP equivalent of the following code:
use cfg;
my %cfg = _config();
make PAST::Val(:value(%cfg<archname>));
$?PARSER should be simply the grammar class name. $?LANG should
always be 'Perl6', unless explicitly overridden with :lang. $?VM and
$?KVM should just be 'Parrot', at present.
Should $?PERL be 'Rakudo' or '/path/to/perl6.pbc'?
I think $?GRAMMAR, $?CLASS, $?ROLE, $?MODULE and $?PACKAGE should be
easy because actions.pm already tracks those values in @?PKGDECL[*-1]
<pkgdecl> (or something like that). @?GRAMMAR, @?CLASS, @?ROLE, @?
MODULE, and @?PACKAGE should be similar operations on @?PKGDECL.
Thoughts?
Chris
