:
M S04-control.pod
Log Message:
---
Refer to Definition of Success near KEEP and UNDO
On Mon, Mar 05, 2007 at 09:01:13AM -0800, Larry Wall wrote:
> I don't see a problem here. I think you maybe missed the bit that says:
>
> A C block sees the lexical scope in which it was defined, but
> its caller is the dynamic location that threw the exception. That is,
> the stack
On Mon, Mar 05, 2007 at 01:06:46PM +, Daniel Hulme wrote:
: What happens if a resumable exception is propagated through a block with
: a LEAVE, KEEP, or UNDO block? S04 seems to be a bit vague on this point.
: It strikes me that what we want it to do is not execute them when the
: exception is
What happens if a resumable exception is propagated through a block with
a LEAVE, KEEP, or UNDO block? S04 seems to be a bit vague on this point.
It strikes me that what we want it to do is not execute them when the
exception is propagated, because we don't know whether it's going to be
be
>> undoable.
>>
> A much more useful way to do this would be:
>
> use undo << $foo $bar $baz >>;
> my $foo = 41;
> my $state = undo.save;
> $foo++; $foo.undo($state); # or perhaps $state.remember;
That seems reasonable to me.
&g
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> writes:
> Actually, I think you're underestimating the little guys. After
> all, if they rolled back *all* of your changes, all they could do
> was repeatedly execute the same code!
Except that you can pass the continuation some arguments, possibly
in
basically. I was just about to mention
hypothetical scoping wrt undo but for some reason did not.
In fairness to the undo suggestion, there is a significant difference:
to use hypotheticals to revert you have to plan the reverting when (or
before) you make the change. I think continuations
Rod Adams wrote:
Well, that's another explanation that jives with my understanding of
them. But I still don't have an idea of when I would actually want
to use them in something I'm writing.
You can use them to implement all sorts of interesting control flow
constructs.
For example, here's
Austin Hastings wrote:
--- Rod Adams <[EMAIL PROTECTED]> wrote:
A guess from my current understanding:
You're wanting to play with a database. You take a continuation. You
see
if have a database handle open and good to go, if so you do your
thing.
(can you then dismiss the continuation? do uni
- Original Message -
From: Luke Palmer <[EMAIL PROTECTED]>
Date: Tuesday, June 29, 2004 7:31 pm
Subject: Re: undo()?
>
> Oh no! Someone doesn't understand continuations! How could this
> happen?! :-)
>
> You need two things to bring the state of the process
--- Rod Adams <[EMAIL PROTECTED]> wrote:
> A guess from my current understanding:
>
> You're wanting to play with a database. You take a continuation. You
> see
> if have a database handle open and good to go, if so you do your
> thing.
> (can you then dismiss the continuation? do uninvoked cont
Brent 'Dax' Royal-Gordon wrote:
David Storrs wrote:
Well, at least that's a nice simple explanation. Why couldn't anyone
have explained it to me that way before? Unfortunately, it means that
continuations are a lot less useful than I thought they were. :<
Actually, I think you're underestimatin
David Storrs wrote:
Well, at least that's a nice simple explanation. Why couldn't anyone
have explained it to me that way before? Unfortunately, it means that
continuations are a lot less useful than I thought they were. :<
Actually, I think you're underestimating the little guys. After all, if
On Tue, 29 Jun 2004, Jonadab the Unsightly One wrote:
> If we have $foo.undo(), then we will want a multi-step undo to go with
> it, probably $foo.undo($n), with $n able to be negative for redo. Are
Definitely! I didn't add that to the point that it wuld have been obvious,
and I wan
On Tue, Jun 29, 2004 at 05:31:29PM -0600, Luke Palmer wrote:
> Oh no! Someone doesn't understand continuations! How could this
> happen?! :-)
>
> You need two things to bring the state of the process back to an earlier
> state: undo and continuations. People say continu
Michele Dondi writes:
> On Tue, 29 Jun 2004, Rafael Garcia-Suarez wrote:
>
>
> > Difficulties: define "history" of a function w.r.t. threads; closures;
> > and system side-effects (writing to files, locking them etc.)
>
>
> On Tue, 29 Jun 2004, Mark A. Biggar wrote:
>
> > Besides we already ha
ave a method to keep track of their
> > history, or, more reasonably, will be *allowed* to have it), but I
> > wonder if Perl6 may include a builtin undo() function to recover
> > values prior, say, to the last assignement (or push() or,
> > etc. etc.[*])
>
> Hmmm...
>
nably, will be *allowed* to have it), but I
> wonder if Perl6 may include a builtin undo() function to recover
> values prior, say, to the last assignement (or push() or,
> etc. etc.[*])
Hmmm...
If we have $foo.undo(), then we will want a multi-step undo to go with
it, probably $foo.undo(
On Tue, 29 Jun 2004, Rafael Garcia-Suarez wrote:
> Difficulties: define "history" of a function w.r.t. threads; closures;
> and system side-effects (writing to files, locking them etc.)
On Tue, 29 Jun 2004, Mark A. Biggar wrote:
> Besides we already have MTOWTDI with local() and hypotheticals.
Sorry I did mean temp.
--
Mark Biggar
[EMAIL PROTECTED]
-- Original message --
> Mark A. Biggar skribis 2004-06-29 9:07 (-0700):
> > Besides we already have MTOWTDI with local() and hypotheticals.
>
> I thought temp replaced local. If not, how do they differ? (is t
Mark A. Biggar skribis 2004-06-29 9:07 (-0700):
> Besides we already have MTOWTDI with local() and hypotheticals.
I thought temp replaced local. If not, how do they differ? (is temp for
lexicals, local for globals (and why would that make sense?))
Juerd
lowed* to have it), but I wonder if Perl6 may
include a builtin undo() function to recover values prior, say, to the
last assignement (or push() or, etc. etc.[*])
Difficulties: define "history" of a function w.r.t. threads; closures;
and system side-effects (writing to files, locking them
o have it), but I wonder if Perl6 may
> include a builtin undo() function to recover values prior, say, to the
> last assignement (or push() or, etc. etc.[*])
Difficulties: define "history" of a function w.r.t. threads; closures;
and system side-effects (writing to files, locking t
ude a builtin undo() function to recover values prior, say, to the
last assignement (or push() or, etc. etc.[*])
For optimization reasons track of a variable's "history" may be kept only
upon explicit appearance of undo()...
[*] To be definite, any atomic value-changing expression
o as $f { ... }
>
> But, I can see how
>
> > for 0 .. Inf; "a" .. "z" x 1000 -> $i; $a {
>
> for 0 .. Inf; "a" .. "z" x 1000 as $i; $a {
>
> would be seen as a counterexample by some.
Yep. By Larry, for one. And me, fo
s too long a name to
> prefix most common exceptions...
>c::NEXT
Based purely on visual impact, c:: seems best.
Perhaps 'when', or CATCH, could cause the parser to automatically
try an Error:: (or Exit:: or whatever) class prefix when it encounters a
classname.
> KEEP b
26 matches
Mail list logo
