Tom Christiansen:
> > Don't we have to solve all this to get the Perl 6 debugger
> > working anyway?
>
> Although I'm unsure why that might be, I also recognize the possibility
> that there may well exist hypothetical documents, unread by me, which
> mandate some scenario or behavior wherein the answer to your question
> can only be yes.
My original thinking behind that question came from a few different
vague questions in my mind about what kind of scope manipulation was
allowed in Perl 6 (and therefore would be expected from the debugger).
Admittedly, there was a certain amount of laziness on my part in going
with my hunch rather than rereading the relevant spec docs ....
For example, it is not clear to me how the Perl 6 debugger can
temporarily unwarp the grammar (to evaluate input using the core
language, instead of whatever abomination is in scope) while still
*otherwise* respecting the local scopes, without having most of the
scope introspection/modification tools fully working.
> [... much detail on why the design of the Perl 5 debugger does not
> allow new persistent lexical variables to be created ...]
Yes, I knew all that, but it's nice to see it all spelled out again in
one place.
> Perhaps you saying that you would *like* to see the perl6 debugger provide
> a facility under which scoped constructs like these could seem to outlive
> their scope, probably by making an allowance so that some sort of variant
> C<eval STRING> construct be made available that's not a disguised C<eval
> {STRING}>, as currently occurs.
Yes. I've wanted that from Perl 5 for ages. I *thought* this was
something I could expect from the improved scope introspection
facilities in Perl 6, but in retrospect I may have filled in gaps in the
spec with my wishful thinking.
> > (Aside from which, it would be useful to have this capability properly
> > exposed, for writing shell-style UIs that can escape to raw Perl.)
>
> Can't see you feel to be stopping you from doing that now, considering that
> many existence-proofs show they already do this. You must be talking about
> some sneaky way to violate the inviolable boundary of scope.
Why yes, I am. :-)
> [... mild prejudice towards a unix view of parents and children ...]
> That is, they wish for changes in their own process to somehow propagate
> *upwards* in a most unnatural fashion to affect those who created them,
> rather than downwards following the natural order of things to affect their
> unborn children.
This model is weak. I understand the reasons for it in the unix world
view, but having worked in programming environments that allowed more
powerful modes of interaction, I don't buy it as the natural order.
(And in fact, the concept of one thing being able to unilateraly affect
another is decidedly non-physical, so calling it "natural" is at best a
misnomer.)
Circling back to Perl -- for me, Perl 6 is all about continuing the
long-standing Perl practice of merging in the best ideas of everyone
else. It's about time we merged the several-decades-old concept of true
first-class support for interactive evaluation. And that means
providing some way to strip the implicit new scope off of eval.
To me, the move to scopeless eval is a shift on the order of the
introduction of closures -- you really don't realize how bloody useful
they are until you have them.
Patrick Michaud:
> Taking a pure Parrot perspective, Parrot doesn't and probably
> shouldn't impose a particular view of debugging on the languages it
> supports. Clearly we can support the style of debugging and
> interactive
> execution that you've described happens with perl 5, but Parrot might
> also come across a dynamic language where eval'd code is "in scope"
> and can modify the current lexical environment. So, while Parrot
> probably won't impose this view on Perl (5 or 6), it may still
> need to evolve to support it at some point.
> From a Perl 6 perspective, given that Pugs provides an interactive
> mode where one can do "my $variable" and have it stick, it
> may be that this becomes a standard feature in Perl 6 in
> general. Fortunately that's not my call, but I can see why people
> may want something like it for Rakudo as well, and people running
> Python on Parrot will certainly expect interactively entered
> lexical variable declarations to work.
Certainly users of other languages also expect to have "real"
interactive modes, wherein declarations persist, so I expect Parrot/PCT
most likely *will* want to support this -- and when the capability is
provided by both Rakudo and Pugs, I'd hope it is not to hard to convince
$Larry to make it official.
-'f
