Conversation
|
No merge before release. |
|
We should avoid methods named identically to those of other core methods that do something completely different (I still 🤦 over creating |
|
@ugexe Good point. I chose "now" because, well because I want a REPL now. Maybe Any suggestions on making it see its context? |
|
@Altai-man Wasn't planning on merging this before release. I changed it to "Draft" to make that clearer! |
|
@lizmat Unfortunately, I can't be really helpful with the context. It looks like it should work. Except that, perhaps, passing it as |
|
I'd probably go more towards something like |
|
|
FWIW, I see this as a debugging tool, so I would like to have it as short as possible. Making it a sub called |
|
|
||
| method here() { | ||
| my $repl := self.new(nqp::getcomp("Raku"),%_); | ||
| nqp::bindattr($repl,REPL,'$!save_ctx',nqp::ctxcaller(nqp::ctx)); |
There was a problem hiding this comment.
This isn't going to go well. The compiler is free to optimize out lexicals as it pleases. We do have a list of magical sub names, such as EVAL, which inhibit compiler optimization in all outer scopes. (Others include eval-lives-ok for Test.) I'm not thrilled about this, but at least hope that list can go away in the future by making all such things instead be macros that do...something...to inhibit the optimizations (the point being that the compiler doesn't need to keep a magical list of names).
But that means the things in question should be sub calls today, not method calls. We do, I grant, have a .EVAL method, which I consider an unfortunate mistake, although we could make that a macro postfix:<.EVAL> or something (and hope it wins on the LTM longest literal prefix rule). (I'd personally lean towards deprecation, though.)
Anyway, if we really should have this, please make it a sub. It'll have to go in the same magical list of optimization inhibitors that EVAL is also in.
There was a problem hiding this comment.
OK, I will make it a sub called repl.
@jnthn where does the magical sub names list live?
There was a problem hiding this comment.
OK, I will make it a sub called repl.
That's succinct.
where does the magical sub names list live?
src/Perl6/Optimizer.nqp I believe.
There was a problem hiding this comment.
Aah, that's why I couldn't find it: eval-lives-ok is not in that list, but throws-like is.
repl sub to enter the repl from within a program
This would allow one to enter the REPL from a non-interactive program. Ideally, this should be aware of its context, but apparently setting $!save_ctx is not enough. Maybe @vrurg has some ideas about that. Sorta inspired by some comments on the #raku channel today.
As indirectly suggested by @ugexe
As suggested by jnthn. Since this is now a globally visible sub, make sure the local tests are adapted for it.
This makes the REPL in:
my $a = 42; repl; say $a
actually know about $a, and allow it to be changed, and see the result
of the change afterwards. jnthn++ for the hint.
But only if called from the repl() sub
|
Trying to catch a user doing Ctrl-d, or resetting the eof / error flag on STDIN, is still out of reach. But at least typing "exit" now in Therefore I marked this PR now ready for review. As this is new functionality not touching on current functionality, I'd say it's pretty safe to merge before 2021.05 release. |
To make clear that typing "exit" is currently the only sane way to exit the repl (without exiting the program). Also prevent warning when CTRL-d ing when called as "repl".
This would allow one to enter the REPL from a non-interactive program.
Ideally, this should be aware of its context, but apparently setting
$!save_ctx is not enough. Maybe @vrurg has some ideas about that.
Sorta inspired by some comments on the #raku channel today.