Re: undo()?
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 continuations are like time traveling; I like to put it this way: Say you're in the kitchen in front of the refrigerator, thinking about a sandwitch. You take a continuation right there and stick it in your pocket. Then you get some turkey and bread out of the refrigerator and make yourself a sandwitch, which is now sitting on the counter. You invoke the continuation in your pocket, and you find yourself standing in front of the refrigerator again, thinking about a sandwitch. But fortunately, there's a sandwitch on the counter, and all the materials used to make it are gone. So you eat it. :-) Urf. Okay, put me on the list as someone who thought he understood continuations at least somewhat but obviously didn't have a clue. I was under the impression that a continuation was the entire state of the program at that point and that, when invoked, it overwrites the current state with the saved one. Therefore, if you invoke a continuation, you are resetting everything to the when it was when the continuation was taken. So external changes (the fact that you wrote to a file) will remain, but internal changes (the fact that you assigned 7 to $foo) will be undone. I'm not sure how some of the edge cases (where things are partially internal and partially external) are supposed to work out, for example: $dbh = connect_to_db_and_prepare_fetch_call(); # save continuation here close_connection_to_db($dbh); # invoke saved continuation here $dbh-fetch_row(); # DB has closed connection so this fails. Needless to say, I have never worked with continuations myself, just studied them very briefly in college (a long time ago). A continuation doesn't save data. It's just a closure that closes over the execution stack (and any lexicals associated with it; thus the I want a sandwitch thought). If things change between the taking and invoking of the continuation, those things remain changed after invoking. 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. : How do continuations and threads interact? When you take a cont, are you taking it only within the current thread? Or does it snapshot all threads in the process? --Dks
Re: The .bytes/.codepoints/.graphemes methods
Larry Wall wrote: On Sat, Jun 26, 2004 at 12:27:38PM -0700, Brent 'Dax' Royal-Gordon wrote: : Issues: : * Limits lvalue substr (doesn't allow it to be a different size) : unless splice is used (or a substr method is also provided). That all has to be looked at anyway. What does 5 mean when you pass it to substr, anyway? (I've been trying to make it assume some implicit unit based on the current lexical scope's Unicode level, but issues remain.) We have magical string positions that have different numeric values depending on what units you view them as, but at what point does a number like 5 get translated to such a magical string position? While we're on the topic of substr, allow me to beg. Please, can we replace substr with with array style operations like Ruby and Python? Please? Something like this would be nice: my $string = Hello, World!; say $string[0..4]; # prints Hello\n $string[7...] = Larry!; say $string; # prints Hello, Larry!\n We already have our strings acting as objects, and we have [] as a postcircumfix operator, so it's something that someone could define easily. Of course, I have no idea how to reconcile this with all the talk of unicode other than to say that the easy stuff should be easy. It just follows this would also be nice for arrays, to replace splice. For me, these two functions are the most bothersome part of Perl 5, and I would love to see them go. matt
Re: This week's Summary
The Perl 6 Summarizer [EMAIL PROTECTED] wrote: Congratulations Ion, don't forget to send in a patch to the CREDITS file. $ grep -1 Ion CREDITS N: Ion Alexandru Morega D: string.pmc Thanks again for your summary, leo
Re: undo()?
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 wanted to keep the message as simple as possible. Not sure about negative values... we prepared to give the mouse that cookie? (This is not intended as a rhetorical question; I suspect people will stake out both positions.) Well, I've slightly changed my mind myself too. As we have Credo, it may make more sense and better fit in the natural-language-like scheme of Perl to have a builtin undo() for blocks, with the obvious caveat that not everything that was done a block can be undo()ne, e.g. wrt removed files et similia... I heard a rumour we were getting continuations (a la Scheme). They Even if it is not expressed properly, I think that the idea hinted at above is more similar to this one. wouldn't be tied to a specific variable like what you propose, but they would allow the state of the entire process to be rolled back to an earlier point, or something along those lines. Of course, the Yep, for sure this makes much more sense! Michele -- (I don't know why I can't resist jumping in on this thread. I wonder if it's a mass hypnosis worm ...) It must be the usenet equivalent of a spectacular car crash, where passersby feel compelled to stop and stare. - Keith Keller in clpmisc, Re: Clarifications
Re: undo()?
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 they rolled back *all* of your changes, all they could do was repeatedly execute the same code! How do continuations and threads interact? When you take a cont, are you taking it only within the current thread? Or does it snapshot all threads in the process? Continuations are an operation on the call stack (although it's usually a call chain for continuations), so a continuation only operates on the current thread. I think. (Incidentally, IIRC you can implement user-mode cooperative threading with continuations--yield() enqueues its return continuation and then dequeues and invokes another thread's continuation. But that's not what you're asking at all.) -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia.
Re: The .bytes/.codepoints/.graphemes methods
Matt Diephouse skribis 2004-06-30 20:51 (-0400): my $string = Hello, World!; say $string[0..4]; # prints Hello\n $string[7...] = Larry!; say $string; # prints Hello, Larry!\n And that array is one of bytes? graphemes? In general, I like the idea. In [EMAIL PROTECTED], almost the same was suggested, but implemented differently: a string's .bytes method in list context (but isn't it array context, technically?) would dwym. As would the other parts-of-string methods. Perhaps without method, the string in array/list context can default to the default set by a lexical pragma. Which, I hope, has a default itself. (I like default defaults...) Juerd
Re: The .bytes/.codepoints/.graphemes methods
Juerd wrote: Matt Diephouse skribis 2004-06-30 20:51 (-0400): my $string = Hello, World!; say $string[0..4]; # prints Hello\n $string[7...] = Larry!; say $string; # prints Hello, Larry!\n And that array is one of bytes? graphemes? I'm not really up on my unicode, but I think .chars is what I have in mind. I want it to operate like a non-unicode string in Perl 5. Anything unicode can be more complex, as I think this will be the common case. In general, I like the idea. In [EMAIL PROTECTED], almost the same was suggested, but implemented differently: a string's .bytes method in list context (but isn't it array context, technically?) would dwym. As would the other parts-of-string methods. Think of this as Huffmanized .chars then? matt
Re: undo()?
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 underestimating the little guys. After all, if they rolled back *all* of your changes, all they could do was repeatedly execute the same code! Hmm... Could someone please give a few prototypical cases where continuations really shine over other methods of structure? 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 continuations pile up somewhere?). If the handle is not ready, you do everything needed to prepare the handle, and then invoke the continuation. But I don't see how a continuation gained you much over Cprepare($dbh) unless ready($dbh);. So what makes them so cool? -- Rod
Re: undo()?
--- 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 continuations pile up somewhere?). If the handle is not ready, you do everything needed to prepare the handle, and then invoke the continuation. But I don't see how a continuation gained you much over Cprepare($dbh) unless ready($dbh);. So what makes them so cool? You know how you can log in to your webmail/slashdot/sourceforge/amazon account, and get a cookie that says you're logged in? And you know how you can then go into your browser's history list and pick up some entry that was invalid, or came from yesterday, and when you click through, the cookie (local data) that says you're legitimately logged in stays with you, so the site doesn't give you a hard time? That's continuation-like behavior. Continuations will let you take function pointers at an arbitrary location: instead of entering the top of the function, you can come in to the middle. They are similar to setjmp/longjmp in this context: you have to pass through once to take the continuation, before you can invoke it. But you can invoke it arbitrarily many times, unlike set-/long-jmp, since the continuation closes over the entire call stack. =Austin
Re: if not C, then what?
On Wed, 2004-06-30 at 21:33, chromatic wrote:
On Wed, 2004-06-30 at 18:18, Alexey Trofimenko wrote:
P.P.S. do we have a way to imply void context on function inside
expression, something like Cscalar, C+, C~, C? do?
Sort of a 'meh' operator?
I wonder (idly) in which circumstances the context determinator couldn't
determinate void context, though.
module foo {
sub a() is export { return 1; }
sub b() is export { a() }
}
Our Huffmanization imperative tells us that this should be a longer
operator than other contextifiers, so why not just the C-like, void?
void foo::b();
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Perl Toolsmith
http://www.ajs.com/~ajs/resume.html
Re: undo()?
- 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 back to an earlierstate: undo and continuations. People say continuations are like time traveling; I like to put it this way: Say you're in the kitchen in front of the refrigerator, thinking about a sandwitch. You take a continuation right there and stick it in your pocket. Then you get some turkey and bread out of the refrigerator and make yourself a sandwitch, which is now sitting on the counter. You invoke the continuation in your pocket, and you find yourself standing in front of the refrigerator again, thinking about a sandwitch. But fortunately, there's a sandwitch on the counter, and all the materials used to make it are gone. So you eat it. :-) A continuation doesn't save data. It's just a closure that closes overthe execution stack (and any lexicals associated with it; thus the I want a sandwitch thought). If things change between the taking and invoking of the continuation, those things remain changed after invoking. You could make the programmer specify which variables he wants delta data for, and then any *others* wouldn't keep it and wouldn't be undoable. use undo foo bar baz; # Or use the funny characters I can't type. my $foo++; $foo.undo(); # Undoes the increment. my $quux++; $quux.undo(); # Throws an exception or something. 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; Do you think it would be possible to implement Cundo with pure Perl6 using continuations? My intuition thinks it could, but my brain starts hating me when I start to think about it... It would definitely be a pretty neat module if it could be done though. P.S. That was a truly spectacular explanation of continuations. :)
Re: if not C, then what?
On Wed, 2004-06-30 at 18:41, Luke Palmer wrote:
Larry didn't go for it. Note, we already have an operator that puts its
left side in void context and evaluates it before its right one: we call
it C;.
But C; requires a surrounding do block, as you noted. I'm
disappointed that Larry didn't go for it. To my eyes, Cthen really
increases readability.
pray_to $_ then sacrifice $virgin for @evil_gods
Ah, yes. That's beautiful.
However,
do { pray_to $_; sacrifice $virgin } for @evil_gods;
Ouch. That bounces and jangles as you try to read it. There appears to
be some sort of deep separation between @evil_gods and sacrificial
$virgin. Cdo appears to be the most important part of this statement,
when it is in fact the _least_ important.
- Scott
Re: if not C, then what?
Scott Bronson skribis 2004-07-01 12:42 (-0700): But C; requires a surrounding do block, as you noted. Then invent a horizontal ; operator that does not :) pray_to $_ then sacrifice $virgin for @evil_gods pray_to $_ ., then sacrifice $virgin for @evil_gods; Juerd
Re: if not C, then what?
On Wed, 30 Jun 2004 19:41:24 -0600, Luke Palmer [EMAIL PROTECTED] wrote:
Alexey Trofimenko writes:
if we really about to lose C-style comma, would we have something new
instead?
new C,,( as I've been told here by wise ones), doesn't guarantee order
in which its operands will be evaluated, and even doesn't guarantee that
they won't be optimised away before evaluating, if all expression is in
void
context.. right?
Nope, that was just silliness. Although the scalar comma is going away
in favor of a list constructor, I presume that there will be no
opimizing away of elements, and that they will probably still be
evaluated left to right. Optimizations that you get from changing the
evaluation order aren't big enough to warrant such a strange semantic
effect.
BUT: the subexpressions will be evaluated in list context.
I'm thinking about Cthen, analogious to old C, (maybe with lower
precedence than Cand and Cor have?)
pray_to $_ then sacrifice $virgin for @evil_gods
hm.. maybe Cthen should make first action in void context (I hate
noise
when doing business)
That's interesting. I brought up the same thing and proposed the same
solution just a few months ago. Same keyword and everything :-)
hm:) I'm sorry for idea stealing. I'm here only month.. Maybe it means
this is natural solution for many people's way of thoughts?..)
Larry didn't go for it. Note, we already have an operator that puts its
left side in void context and evaluates it before its right one: we call
it C;.
Larry didn't go.. ok, that is it! I Want To Write My Own Grammar(TM) :)
Just because that construct would be more useful for me than many we
already have in the core. Now I'm interesting, would it be difficult. That
is - would it be difficult to write operator, which evaluates it's left
operand in void context, and do not tries to store results or to create
lists or all the unneded activity wich C, will do.. (I suspicious to
macroses - they could have their major caveat, we just not find it yet..)
BTW is C; an operator really? :) if it is, then it has lower precedence
than statement modifers, and that means that they are really operators
too, which leads us to thinking about several modifiers possibility
(again!).. but Larry didn't go for it, I know :)
@
do { pray_to $_; sacrifice $virgin } for @evil_gods;
Luke
note about Cdo - I think ret() mentioned in one of Apocalypses should be
in core.. just because it's sometimes too difficult (i'm lazy) to place
return value at the end of complicated Cdo, Cmap, Cgrep etc blocks.
If I use curlies, I place a whole program in it:)
and, again about C,
what about C,, ? what it would do? in perl5 this has no effect, but what
about perl6? (something tells me that it would be compile time error
probably.)
maybe (1,,2) could be the same as (1,undef,2)? but someone immediately
will write subroutine callable as
mysub 1,2,3,,,4
perl gives a lot of freedom, and I like that.. but do we allow such
silliness? :)
(P.S. my lazyness murmurs to me that ,, would be niccce.. oh my.. no-o!)
Re: The .bytes/.codepoints/.graphemes methods
On Thu, 1 Jul 2004, Juerd wrote: Matt Diephouse skribis 2004-06-30 20:51 (-0400): my $string = Hello, World!; say $string[0..4]; # prints Hello\n $string[7...] = Larry!; say $string; # prints Hello, Larry!\n And that array is one of bytes? graphemes? In general, I like the idea. In [EMAIL PROTECTED], almost the same was suggested, but implemented differently: a string's .bytes method in list context (but isn't it array context, technically?) would dwym. As would the other parts-of-string methods. What if you could add the slice onto the method: my $string = Hello, World!; say $string.bytes[0..4]; # prints Hello\n $string.codepoints[7...] = Søren!; say $string; # prints Hello, Søren!\n The string slicing operator would have to return an array of bytes/codepoints/etc in list context and a substr in scalar context. ~ John Williams
Re: if not C, then what?
On Thu, 2004-07-01 at 12:45, Juerd wrote: Scott Bronson skribis 2004-07-01 12:42 (-0700): But C; requires a surrounding do block, as you noted. Then invent a horizontal ; operator that does not :) Cthen? That's the topic of discussion... pray_to $_ then sacrifice $virgin for @evil_gods pray_to $_ ., then sacrifice $virgin for @evil_gods; Sure. But what is .,? Cthen could work alone, couldn't it?
Re: if not C, then what?
Scott Bronson skribis 2004-07-01 13:31 (-0700): Then invent a horizontal ; operator that does not :) pray_to $_ then sacrifice $virgin for @evil_gods pray_to $_ ., then sacrifice $virgin for @evil_gods; Sure. But what is .,? Cthen could work alone, couldn't it? It is a horizontal ;. See: ., If you turn your head 90 degrees counter clockwise, you see the horizontal semicolon and even a smiley face :) Juerd
Re: if not C, then what?
Scott Bronson wrote:
On Wed, 2004-06-30 at 18:41, Luke Palmer wrote:
Larry didn't go for it. Note, we already have an operator that puts
its left side in void context and evaluates it before its right one:
we call it C;.
But C; requires a surrounding do block, as you noted. I'm
disappointed that Larry didn't go for it. To my eyes, Cthen really
increases readability.
All's fair if you predeclare:
sub infix:then (first, last) {
first();
return last();
}
The only problem I see with this solution is that I don't think that you
can pass individual commands into code variables:
pray_to $_ then sacrifice $virgin for @evil_gods;
would be wrong, but
{pray_to $_} then {sacrifice $virgin} for @evil_gods;
would work. Am I right about this, or does perl 6 let you pass simple
statements as code parameters? If the former, is there a way to tell it
to do the latter?
For the record, I was mentally parsing this example as:
pray_to $_;
sacrifice $virgin for @evil_gods;
rather than:
{pray_to $_; sacrifice $virgin} for @evil_gods;
The precedence of Cthen isn't very intuitive to me.
=
Jonathan Dataweaver Lang
__
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail
Re: if not C, then what?
On Thu, 2004-07-01 at 13:35, Juerd wrote: pray_to $_ ., then sacrifice $virgin for @evil_gods; Sure. But what is .,? Cthen could work alone, couldn't it? It is a horizontal ;. Ha! I love it. Good source code should look happy.
Re: if not C, then what?
Scott Bronson skribis 2004-07-01 14:11 (-0700): On Thu, 2004-07-01 at 13:35, Juerd wrote: pray_to $_ ., then sacrifice $virgin for @evil_gods; I meant it without then, but apparently forgot to remove it. pray to $_ ., sacrifice $virgin for @evil_gods; Ha! I love it. Good source code should look happy. I'm glad you like it :) Juerd
Re: undo()?
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 uninvoked continuations pile up somewhere?). If the handle is not ready, you do everything needed to prepare the handle, and then invoke the continuation. But I don't see how a continuation gained you much over Cprepare($dbh) unless ready($dbh);. So what makes them so cool? You know how you can log in to your webmail/slashdot/sourceforge/amazon account, and get a cookie that says you're logged in? And you know how you can then go into your browser's history list and pick up some entry that was invalid, or came from yesterday, and when you click through, the cookie (local data) that says you're legitimately logged in stays with you, so the site doesn't give you a hard time? That's continuation-like behavior. Continuations will let you take function pointers at an arbitrary location: instead of entering the top of the function, you can come in to the middle. They are similar to setjmp/longjmp in this context: you have to pass through once to take the continuation, before you can invoke it. But you can invoke it arbitrarily many times, unlike set-/long-jmp, since the continuation closes over the entire call stack. =Austin 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. -- Rod
Re: if not C, then what?
Juerd wrote:
Scott Bronson skribis 2004-07-01 14:11 (-0700):
Juerd wrote:
pray_to $_ ., then sacrifice $virgin for @evil_gods;
I meant it without then, but apparently forgot to remove it.
pray to $_ ., sacrifice $virgin for @evil_gods;
Strictly from a grammatical perspective, I'd be much more comfortable with
C, then instead of Cthen as the perl equivelent of the C-style comma:
have the then keyword change the preceeding comma from a list
constructor to an expression combiner. From a parsing perspective,
though, this would be a nightmare.
Actually, the whole purpose of the C-style comma is to allow you to place
multiple expressions in a place that's only designed to take one, such as
the various divisions within a loop control set (loop ($i = 0, $j = 1; $i
10; $i++, $j*=2) {...}). For something like this, you might be better
off doing something like
last($a, $b, $c)
instead of
$a then $b then $c
(where last is a sub that takes a list of arguments, evaluates them one at
a time, and returns the value of the last one). Unfortunately, last is
already in use by perl; so you'd have to think up another name for the
sub, such as final.
If you're really enamoured with the infix operator syntax, consider this
possibility:
sub infix:- ($before, $after) {
$before; # is this line redundant?
return $after;
}
print $a - $b - $c; # prints $c
where C[-] is read as followed by. You could even set up a
right-to-left version, C[-], but why bother?
=
Jonathan Dataweaver Lang
__
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail
