On Sun, Feb 15, 2009 at 03:48:04PM -0600, Chris Dolan wrote: > 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.
Correct, and this is a planned change for PGE in the *very* near future, as soon as I can get some of the other bits of Rakudo to settle out. > 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>)); Assuming that $?OS is simply a string, this is correct. I think the above can even be implemented now (changing the assignment to binding so it works in NQP). > $?PARSER should be simply the grammar class name. I disagree on this one -- I suspect it should point to the parser itself, and not just the name of the grammar class. > $?LANG should always be > 'Perl6', unless explicitly overridden with :lang. $?VM and $?KVM should > just be 'Parrot', at present. Assuming that these values are indeed strings (and not more sophisticated objects), then yes. > 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). They're likely doable, yes. I'm not entirely certain how to handle the case of anonymous grammars, classes, roles, etc. -- those lookups may be a bit trickier. Pm
