structures are subject to change over time; it is therefore erroneous
to pass junctions to any control construct that is not implemented via
as a normal single or multi dispatch. In particular, threading
junctions through conditionals correctly could involve continuations,
which are almost but n
Andrew Whitworth wrote:
> The issue mentioned in the Synopses is that junctions autothread, and
> autothreading in a conditional could potentially create multiple
> threads of execution, all of which are taking different execution
> paths. At some point, to bring it all back together again, the var
l single or multi dispatch. In particular, threading
> junctions through conditionals correctly could involve continuations,
> which are almost but not quite mandated in Perl 6.0.0."
> What is a continuation?
Continuation here is meant in the most generic sense, which is:
"The
re subject to change over time; it is therefore erroneous
>> to pass junctions to any control construct that is not implemented via
>> as a normal single or multi dispatch. In particular, threading
>> junctions through conditionals correctly could involve continuations,
>>
a normal single or multi dispatch. In particular, threading
junctions through conditionals correctly could involve continuations,
which are almost but not quite mandated in Perl 6.0.0."
What is a continuation?
<http://en.wikipedia.org/wiki/Continuation>
Early on, Perl 6 discussio
hreading
junctions through conditionals correctly could involve continuations,
which are almost but not quite mandated in Perl 6.0.0."
What is a continuation?
--
Jonathan "Dataweaver" Lang
functional features will make it
: into Perl6. I know we already got currying.
A lot of features are making it into Perl 6 that have historically been
associated with "functional" programming. Off the top of my head:
currying
continuations
tail recursion
laziness
a
On Fri, Apr 22, 2005 at 09:32:55AM -0700, Larry Wall wrote:
Thank you for your detailled answer. I still don't get what you mean
by "[] pattern matching arguments".
Do you mean smart pattern matching on composite values?
>
> A lot of features are making it into Perl 6 that have historically
On Fri, Apr 22, 2005 at 08:13:58PM +0200, Stéphane Payrard wrote:
> On Fri, Apr 22, 2005 at 09:32:55AM -0700, Larry Wall wrote:
>
> Thank you for your detailled answer. I still don't get what you mean
> by "[] pattern matching arguments".
> Do you mean smart pattern matching on composite value
Hi,
I am making a presentation about Perl6 this week end. My point will
be: the next generation of applicative languages will be scripting
languages because they have come of age.
Alternatives don't cut it anymore. Indeed C and C++ are memory
allocation nightmare; Java and C# don't have read-ev
On Thu, 21 Apr 2005 08:36:28 -0700, [EMAIL PROTECTED] (Larry Wall) wrote:
>
> Hmm, maybe that's not such a bad policy. I wonder what other "dangerous"
> modules we might have. Ada had UNCHECKED_TYPE_CONVERSION, for instance.
>
How about
use RE_EVAL; # or should that be REALLY_EVIL?
>
On Thu, Apr 21, 2005 at 04:30:07PM +0300, wolverian wrote:
: On Tue, Apr 12, 2005 at 04:17:56AM -0700, Larry Wall wrote:
: > We'll make continuations available in Perl for people who ask for
: > them specially, but we're not going to leave them sitting out in the
: > open where
On Tue, Apr 12, 2005 at 04:17:56AM -0700, Larry Wall wrote:
> We'll make continuations available in Perl for people who ask for
> them specially, but we're not going to leave them sitting out in the
> open where some poor benighted pilgrim might trip over them unawares.
Sorry f
I'm thinking the
> : >> answer to your question is yes.
> : >
> : > Yes. I want to know how Perl 6 exposes continuations, and how to get one
> : > for, say, the current lexical scope, and if it has a method on it that
> : > lets me evaluate code in that cont
ndering about. I'm sorry I was so unclear.
: >
: >> Can you tell me what your idea of a "scope" is? I'm thinking a
: >> continuation, and if that is what you are thinking, I'm thinking the
: >> answer to your question is yes.
: >
: > Yes. I want
l me what your idea of a "scope" is? I'm thinking a
>> continuation, and if that is what you are thinking, I'm thinking the
>> answer to your question is yes.
>
> Yes. I want to know how Perl 6 exposes continuations, and how to get one
> for, say, the current
tinuation, and if that is what you are thinking, I'm thinking the
> answer to your question is yes.
Yes. I want to know how Perl 6 exposes continuations, and how to get one
for, say, the current lexical scope, and if it has a method on it that
lets me evaluate code in that context
'm looking for a way to refer to scopes
programmatically. I'm also asking if they are continuations, or blocks,
or coderefs, or are those all the same?
The two things you mention are effects of being able to refer to scopes
in such a fashion. I do want both, but the real question isn
efs/scopes continuations? Should .eval be a method
in Continuation?
I'm having a bit of trouble following you, but I can tell you that the VM
portion
treats continuations as well as lexical scopes or pads as first class Parrot
objects (or PMCs).
I cannot say how much Perl6 will expose to
On Fri, Apr 08, 2005 at 05:03:11PM +0300, wolverian wrote:
Hi wolverian,
> one day a friend asked if Perl 5 had a REPL facility.
> (Read-Eval-Print-Loop). I told him it has perl -de0, which is different
> [...]
> In Perl 6, the generic solution to fix this (if one wants to fix it)
> seems, to me,
uld be a method on coderefs
or blocks. Is there a difference between the two? I always hated this
about Ruby; there seems to be no practical value to the separation.
Also, are blocks/coderefs/scopes continuations? Should .eval be a method
in Continuation?
Thanks,
--
wolverian
signature.
Oops, I just noticed Sean had mailed Dan and me privately, not on the list..
sorry for sending the reply here :-)
--
Matthijs van Duin -- May the Forth be with you!
On Thu, Mar 20, 2003 at 11:38:31AM -0800, Sean O'Rourke wrote:
Here's what I take to be a (scheme) prototype of Matthijs' "success
continuations" approach. It actually works mostly by passing closures and
a state object, ...
Matthijs -- is this what you're describi
ot;I don't see why anyone
would ...", Damian immediately posts an example of why.
No problem since it works fine in my model (I had already mentioned that
earlier) - I just said *I* don't see why anyone would.. :-)
So, stop talking about rexen. When everyone groks how continu
ntrol action, it should undo. If let is a data
action, it should not. To me, C is an explicit
action taken against a variable, and should not be
undone by this. (Of course, if unwinding the call stack
causes the variable to go out of scope, it&#
At 12:00 AM + 3/20/03, Simon Cozens wrote:
[EMAIL PROTECTED] (Matthijs Van Duin) writes:
OK, I suppose that works although that still means you're moving the
complexity from the perl implementation to its usage: in this case,
the perl 6 parser which is written in perl 6
No, I don't believe t
[EMAIL PROTECTED] (Matthijs Van Duin) writes:
> OK, I suppose that works although that still means you're moving the
> complexity from the perl implementation to its usage: in this case,
> the perl 6 parser which is written in perl 6
No, I don't believe that's what's happening. My concern is that
o do that. Now that I think of it, temporizing shared
variables is equally bad news, so this isn't something new.
(Which makes continuations potentially more expensive as you need to
then save off more info so on invocation you can restore the
hypothetical state)
Actually, I think 'let
control modification (in which case it
should), and do you restore the hypothetical value at the time the
continuation was taken or just re-hypotheticalize the variables?
(Which makes continuations potentially more expensive as you need to
then save off more info so on invocation you can restore
call
the coroutine again, $y will be de-hypothesized. If the coroutine then
hypothesizes $z and yields out, $z will be de-hypothesized and $y
re-hypothesized. $x will be unaffected by all this
and when hypotheticals are visible to other threads.
I haven't thought of that, but to be ho
At 8:04 PM +0100 3/19/03, Matthijs van Duin wrote:
On Wed, Mar 19, 2003 at 12:35:19PM -0500, Dan Sugalski wrote:
I'll nudge Larry to add it explicitly, but in general redefinitons
of code that you're in the middle of executing don't take effect
immediately, and it's not really any different for r
On Wed, Mar 19, 2003 at 12:35:19PM -0500, Dan Sugalski wrote:
Then I wasn't clear enough, sorry. This is perl -- the state of
something at compile time is just a suggestion as to how things
ultimately work.
Yes, hence my surprise about actually inlining stuff, luckily that was
just a misundersta
I would like to express my sincere gratitude to all of you for working
through these issues. I bent my brain on the Perl 5 regex engine,
and that was just a "simple" recurse-on-success engine--and I'm not
the only person it drove mad. I deeply appreciate that Perl 6's
regex engine may drive you e
[EMAIL PROTECTED] (Dan Sugalski) writes:
> >Compilation's just execution of a regex, albeit the Perl6::Grammar::program
> >regex, and that regex will need to be modified while it's in operation in
> >order to pick up macro "is parsed" definitions and apply them to the rest
> >of what it's parsing.
At 5:54 PM + 3/19/03, Simon Cozens wrote:
[EMAIL PROTECTED] (Dan Sugalski) writes:
At 5:47 PM + 3/19/03, Simon Cozens wrote:
>[EMAIL PROTECTED] (Dan Sugalski) writes:
>> you aren't allowed to selectively redefine
>> rules in the middle of a regex that uses those rules.
>
>This is pr
[EMAIL PROTECTED] (Dan Sugalski) writes:
> At 5:47 PM + 3/19/03, Simon Cozens wrote:
> >[EMAIL PROTECTED] (Dan Sugalski) writes:
> >> you aren't allowed to selectively redefine
> >> rules in the middle of a regex that uses those rules.
> >
> >This is precisely what a macro does.
>
> Not once
At 5:47 PM + 3/19/03, Simon Cozens wrote:
[EMAIL PROTECTED] (Dan Sugalski) writes:
you aren't allowed to selectively redefine
rules in the middle of a regex that uses those rules.
This is precisely what a macro does.
Not once execution starts, no.
--
Da
[EMAIL PROTECTED] (Dan Sugalski) writes:
> you aren't allowed to selectively redefine
> rules in the middle of a regex that uses those rules.
This is precisely what a macro does.
--
"How should I know if it works? That's what beta testers are for. I only
coded it."
(Attributed to Linus Torvald
and I very much want to stomp out any
constructs that will force slow code execution. Yes, I may lose, but
if I don't try...
My job, after all, is to make it go fast. If you want something
that'll require things to be slow then I don't want you to have it. :)
There's issues with h
At 10:41 AM -0600 3/19/03, Jonathan Scott Duff wrote:
On Wed, Mar 19, 2003 at 11:09:01AM -0500, Dan Sugalski wrote:
By the time the regex is actually executed, it's fully specified. By
definition if nothing else--you aren't allowed to selectively
redefine rules in the middle of a regex that uses
On Wed, 19 Mar 2003, Jonathan Scott Duff wrote:
> Are you implying that
>
> $fred = rx/fred/;
> $string ~~ m:w/ <$fred> { $fred = rx/barney/; } rubble /
>
> won't match "barney rubble"?
Or, worse, that
$fred = rx/fred/;
$string ~~ m:w/ { $fred = rx/barney/; } <$fred> rub
On Wed, Mar 19, 2003 at 11:09:01AM -0500, Dan Sugalski wrote:
> By the time the regex is actually executed, it's fully specified. By
> definition if nothing else--you aren't allowed to selectively
> redefine rules in the middle of a regex that uses those rules. Or,
> rather, you can but the upda
Matthijs van Duin wrote:
sweepoff# or bus error
collectoff# or segmentation fault
Please try :
/* set this to 1 for tracing the system stack and processor registers */
#define TRACE_SYSTEM_AREAS 1
in dod.c (works for me).
Though I don't know, if processor registers on PPC gets tr
tion, especially for something like this,
I think we should be careful with introducing mandatory restrictions just
to aid optimization. ("is inline" will allow such optimizations ofcourse)
There's issues with hypothetical variables and continuations. (And
with coroutines as well)
hose rules. Or,
rather, you can but the update won't take effect until after the end
of the regex, the same way that you can't redefine a sub you're in
the middle of executing. (And yes, I'm aware that if you do that
you'll pick up the new version if you recursively call, b
e foo { +? }
}
What you say is only allowed if I put "is inline" on foo.
continuations don't quite work
Care to elaborate on that? I'd say they work fine
We do, after all, want this fast, right?
Ofcourse, and we should optimize as much as we can - but not optimize
*more* than we
uch a subroutine as a
macro. For this to work, if we had:
foo: \w+?
bar: [plugh]{2,5}
then what the regex engine *really* got to compile would be:
(\w+?) ([plugh]{2,5})
with names attached to the two paren groups. Treating them as actual
subroutines leads to madness, continuations don&#x
inary subs, and have them push marks onto the regex stack
before they return. I'm not sure if this can be made to work with
hypotheticals, and I'm sure it won't interact kindly with
continuation-taking, but there's _something_.
As for the interaction with continuations, I was
mance here that the
results I may find in these tests are unlikely to have any relation to
the performance of rules in practice.
1. making continuations affects the performance of *other* code (COW)
2. the "let" operation is missing and all attempts to fake it are silly
3. to really
On Wed, Mar 19, 2003 at 01:01:28PM +0100, Matthijs van Duin wrote:
On Wed, Mar 19, 2003 at 10:38:54AM +0100, Leopold Toetsch wrote:
I would propose, estimate the ops you need and test it :)
Hmm, good point
Or even better.. I should just implement both examples and benchmark them;
they're simple e
On Wed, Mar 19, 2003 at 10:38:54AM +0100, Leopold Toetsch wrote:
I would propose, estimate the ops you need and test it :)
Hmm, good point
Or even better.. I should just implement both examples and benchmark them;
they're simple enough and the ops are available.
I guess it's time to familiarize
Matthijs van Duin wrote:
Which system is likely to run faster on parrot?
I would propose, estimate the ops you need and test it :)
E.g. call a continuation 1e6 times and communicate state with one global
(a lexical is probably the same speed, i.e. a hash lookup)
$ cat a.pasm
new P5, .Perl
hich has already returned. Are you saying every rule will be
an explicit state machine?
This has the advantage that C behaves consistently with the
rest of Perl
What do you mean?
I looked around in Parrot a little, and it seems like continuations
are done pretty efficiently.
Yes, I no
just return a failure-reporting
value... same difference, more or less). This has the advantage that
C behaves consistently with the rest of Perl. It has the
disadvantage that we have to manually implement backtracking through
individual rules. It has the advantage that it's easier to optimiz
e impression earlier that there isn't any yet for invoking
subrules :-)
Anyway, I will use the following grammar for examples:
rule foo { a }
rule bar { a+ }
rule quux { ab }
rule test { [ | ] }
==== Mechanism 1 -- Continuations
Continuations can be used to reset the "
=head1 C and Continuations
Here's another "blend known paradigms" document from Luke. The idea
is to rethink C to provide even more information than it
already does, in an elegant way. To get us started:
As in Perl 5, the C function will return information about
the dyn
Damian Conway writes:
>
> There's no second iterator. Just C walking through an array.
>
( questions in the form of answers :-)
so :
* "for" impose array context for first argument and doesnt care about
"nature" of the array which it was given eventually as an argument .
no multiple st
3a- Does imposing Damian's iterator-based semantics for coroutines
(and, in fact, imposing his definition of "any sub-with-yield ==
coroutine") cause loss of desirable capability?
No. Not compared to other potential coroutine semantics.
> 3b- Is there a corresponding linkage be
Arcadi wrote:
> > > > while <$iter> {...} # Iterate until $iter.each returns false?
> you mean "Iterate until $iter.next returns false?"
Oops. Quite so.
what is the difference between the Iterator and lazy array ?
am I right that it is just "interface" : lazy array is an iterator
Paul Johnson wrote:
Is it illegal now to use quotes in qw()?
Nope. Only as the very first character of a <<...>>.
Paging Mr Cozens. ;-)
It's just another instance of whitespace significance.
print «\"a" "b" "c"»;
Presumably without the backslash here too.
Maybe. It depends on whet
osing Damian's iterator-based semantics for coroutines
(and, in fact, imposing his definition of "any sub-with-yield ==
coroutine") cause loss of desirable capability? (Asked in ignorance --
the only coroutines I've ever dealt with were written in assembly
language, so I don't
Damian Conway writes:
> David Wheeler asked:
>
> > How will while behave?
>
> C evaluates its first argument in scalar context, so:
>
>
> > while <$fh> {...}# Iterate until $fh.readline returns EOF?
>
> More or less. Technically: call <$fh.next> and execute the loop
> body i
--- Damian Conway <[EMAIL PROTECTED]> wrote:
> Iain 'Spoon' Truskett wrote:
>
> >>> @a ???+??? @b
> >>> @a ???+??? @b
> >
> > Y'know, for those of us who still haven't set up Unicode, they look
> > remarkably similar =)
>
> "Think Of It As Evolution In Action"
>
> ;-)
This coming from som
Damian Conway said:
>> Is it illegal now to use quotes in qw()?
>
> Nope. Only as the very first character of a <<...>>.
Paging Mr Cozens. ;-)
> So any of these are still fine:
>
> print << "a" "b" "c" >>;
> print <<\"a" "b" "c">>;
> print «\"a" "b" "c"»;
Presumably without
On Monday, November 18, 2002, at 08:19 PM, Damian Conway wrote:
(B
(B>> What was the final syntax for vector ops?
(B>> @a $B"c(B+$B"d(B @b
(B>> @a $B"d(B+$B"c(B @b
(B>
(B> The latter (this week, at least ;-).
(B
(BThis reminds me: I though of another set of bracing characte
Iain 'Spoon' Truskett wrote:
@a ???+??? @b
@a ???+??? @b
Y'know, for those of us who still haven't set up Unicode, they look
remarkably similar =)
"Think Of It As Evolution In Action"
;-)
Damian
On Monday, November 18, 2002, at 08:17 PM, Damian Conway wrote:
Sure. C always evaluates its condition in a scalar context.
Oh, duh. Thanks.
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.w
* Damian Conway ([EMAIL PROTECTED]) [19 Nov 2002 15:19]:
> Luke Palmer asked:
> > What was the final syntax for vector ops?
> >
> >@a ???+??? @b
> >@a ???+??? @b
> The latter (this week, at least ;-).
Y'know, for those of us who still haven't set up Unicode, they look
remarkably similar =
Luke Palmer asked:
What was the final syntax for vector ops?
@a ≪+≫ @b
@a ≫+≪ @b
The latter (this week, at least ;-).
Damian
David Wheeler asked:
while <$fh> {...}# Iterate until $fh.readline returns EOF?
That's a scalar context?
Sure. C always evaluates its condition in a scalar context.
Damian
> Date: Tue, 19 Nov 2002 14:29:46 +1100
> From: Damian Conway <[EMAIL PROTECTED]>
>
> Ken Fox lamented:
>
> >> Or the circumfix <<...>> operator. Which is the problem here.
> >
> > This is like playing poker with God.
>
> I hear God prefers dice.
>
>
> > What does the circumfix <<...>> opera
On Monday, November 18, 2002, at 08:05 PM, Damian Conway wrote:
while <$fh> {...}# Iterate until $fh.readline returns EOF?
More or less. Technically: call <$fh.next> and execute the loop body
if that method
returns true. Whether it still has the automatic binding to $_ and the
implic
David Wheeler asked:
How will while behave?
C evaluates its first argument in scalar context, so:
while <$fh> {...}# Iterate until $fh.readline returns EOF?
More or less. Technically: call <$fh.next> and execute the loop body if that method
returns true. Whether it still has the au
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> X-Sent: 19 Nov 2002 02:51:54 GMT
> Date: Tue, 19 Nov 2002 13:51:56 +1100
> From: Damian Conway <[EMAIL PROTECTED]>
> X-Accept-Language: en, en-us
> Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> X-SMTPD: qpsmtpd/0.12, http://develooper.com/co
On Monday, November 18, 2002, at 06:51 PM, Damian Conway wrote:
for <$fh> {...}# Build and then iterate a lazy array (the elements
# of which call back to the filehandle's input
# retrieval coroutine)
for <$iter> {...} # Build and then iterate a lazy array (the elements
Seriously, that's a good trick. How does it work? What do these
examples do?
print <<"a" "b" "c">>;
Squawks about finding the string "b" immediately after the heredoc introducer.
print <<"a"
"b"
"c">>;
Likewise.
Is it illegal now to use quotes in qw()?
Nope. Onl
Damian Conway wrote:
It's [<<...>>>] the ASCII synonym for the «...» operator, which
is a synonym for the qw/.../ operator.
Nope. Heredocs still start with <<.
Hey! Where'd *that* card come from? ;)
Seriously, that's a good trick. How does it work? What do these
examples do?
print <<"a" "
Ken Fox lamented:
Or the circumfix <<...>> operator. Which is the problem here.
This is like playing poker with God.
I hear God prefers dice.
What does the circumfix <<...>> operator do?
It's the ASCII synonym for the «...» operator, which is a
synonym for the qw/.../ operator.
Here d
Damian Conway wrote:
Ken Fox wrote:
The < must begin the circumfix <> operator.
Or the circumfix <<...>> operator. Which is the problem here.
This is like playing poker with God. Assuming you can get over
the little hurdles of Free Will and Omniscience, there's still
the problem of Him pullin
Larry wrote:
So you can do it any of these ways:
for <$dance> {
for $dance.each {
for each $dance: {
^ note colon
Then there's this approach to auto-iteration:
my @dance := Iterator.new(@squares);
for @dance {
Okay, so now I need to make sense of the
On Tue, Nov 19, 2002 at 08:53:17AM +1100, Damian Conway wrote:
: my $dance = Iterator.new(@squares);
: for $dance {
Scalar variables have to stay scalar in list context, so $dance cannot
suddenly start behaving like a list. Something must tell the scalar
to behave like a list, and I don't
--- Damian Conway <[EMAIL PROTECTED]> wrote:
> Austin Hastings asked:
> > That is, can I say
> >
> > for (@squares)
> > {
> > ...
> > if $special.instructions eq 'Advance three spaces'
> > {
> > $_.next.next.next;
> > }
> > ...
> > }
> >
> > or some other suchlike thing that will
Austin Hastings asked:
By extension, if it is NOT given an iterator object, will it appear to
create one?
Yep.
That is, can I say
for (@squares)
{
...
if $special.instructions eq 'Advance three spaces'
{
$_.next.next.next;
}
...
}
or some other suchlike thing that will enab
Ken Fox wrote:
Damian Conway wrote:
my $iter = fibses();
for < <$iter> > {...}
(Careful with those single angles, Eugene!)
Operator << isn't legal when the grammar is expecting an
expression, right?
Right.
The < must begin the circumfix <> operator.
Or the circumfix <<...>> op
--- Damian Conway <[EMAIL PROTECTED]> wrote:
> The semantics of C would simply be that if it is given an
> iterator object (rather than a list or array), then it calls
> that object's iterator once per loop.
By extension, if it is NOT given an iterator object, will it appear to
create one?
That
Damian Conway wrote:
my $iter = fibses();
for < <$iter> > {...}
(Careful with those single angles, Eugene!)
Operator << isn't legal when the grammar is expecting an
expression, right? The < must begin the circumfix <> operator.
Is the grammar being weakened so that yacc can handle it?
Luke Palmer enquired:
we still have implicit iteration:
for fibs() {
print "Now $_ rabbits\n";
}
Really? What if fibs() is a coroutine that returns lists (Fibonacci
lists, no less), and you just want to iterate over one of them? The
syntax:
for &fibs {
print "
> Date: Mon, 18 Nov 2002 09:28:59 +1100
> From: Damian Conway <[EMAIL PROTECTED]>
I've a couple of questions here:
> we still have implicit iteration:
>
> for fibs() {
> print "Now $_ rabbits\n";
> }
Really? What if fibs() is a coroutine that returns lists (Fibonacci
lists,
Of course, apart from the "call-with-new-args" behaviour, having
Pythonic coroutines isn't noticably less powerful. Given:
sub fibs ($a = 0 is copy, $b = 1 is copy) {
loop {
yield $b;
($a, $b) = ($b, $a+b);
}
}
we still have implicit iteration:
Angel Faus wrote:
I understand that this formulation is more powefull, but one thing I like
about python's way (where a coroutine is just a funny way to generate lazy
arrays) is that it lets you _use_ coroutines without even knowing what they
are about.
Such as when you say:
for $graph.nodes {
At 1:29 PM +1100 11/17/02, Damian Conway wrote:
The formulation of coroutines I favour doesn't work like that.
Every time you call a suspended coroutine it resumes from immediately
after the previous C than suspended it. *And* that C
returns the new argument list with which it was resumed.
Hrm.
Damian Conway wrote:
>
> The formulation of coroutines I favour doesn't work like that.
>
> Every time you call a suspended coroutine it resumes from immediately
> after the previous C than suspended it. *And* that C
> returns the new argument list with which it was resumed.
>
> So you can write th
Dan Sugalski wrote:
I dunno. One of the things I've seen with coroutines is that as long as
you call them with no arguments, you get another iteration of the
coroutine--you actually had to call it with new arguments to reset the
thing.
The formulation of coroutines I favour doesn't work like
At 8:31 AM +1100 11/17/02, Damian Conway wrote:
Peter Haworth asked:
So to get the same yield context, each call to the coroutine has to be from
the same calling frame. If you want to get several values from the same
coroutine, but from different calling contexts, can you avoid the need to
wrap
Peter Haworth asked:
So to get the same yield context, each call to the coroutine has to be from
the same calling frame. If you want to get several values from the same
coroutine, but from different calling contexts, can you avoid the need to
wrap it in a closure?
I don't think so.
Damian
On Tue, 12 Nov 2002 14:30:24 +, Peter Haworth wrote:
> So to get the same yield context, each call to the coroutine has to be from
> the same calling frame. If you want to get several values from the same
> coroutine, but from different calling contexts, can you avoid the need to
> wrap it in a
On Wed, 06 Nov 2002 10:38:45 +1100, Damian Conway wrote:
> Luke Palmer wrote:
> > I just need a little clarification about yield().
>
> C is exactly like a C, except that when you
> call the subroutine next time, it resumes from after the C.
>
> > how do you tell the difference between a
> > recu
Luke Palmer wrote:
I just need a little clarification about yield().
The first point of clarification is that the subject is a little off.
C gives us *co-routines*, not *continuations*.
consider this sub:
sub iterate(@foo) {
yield for @foo;
undef;
}
(Where yield defaults to the
I just need a little clarification about yield().
consider this sub:
sub iterate(@foo) {
yield for @foo;
undef;
}
(Where yield defaults to the topic) Presumably.
@a = (1, 2, 3, 4, 5);
while($_ = iterate @a) {
print
}
Will print "12345". Or is that
On Tue, 9 Jul 2002 16:42:03 +0100, Peter Haworth wrote:
> > When you invoke a continuation you put the call scratchpads and lexical
> > scratchpads back to the state they were when you took the continuation.
>
> If you restore the lexicals, how does this ever finish?
Never mind. It's the *acces
1 - 100 of 111 matches
Mail list logo
