RE: Continuations

2002-11-17 Thread Angel Faus
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

Re: Continuations

2002-11-17 Thread Dan Sugalski
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.

Re: String concatentation operator

2002-11-17 Thread Dan Sugalski
At 12:46 PM +1100 11/17/02, Damian Conway wrote: Dan Sugalski pondered: What does: > $foo = any(Bar::new, Baz::new, Xyzzy::new); $foo.run; do? Creates a disjunction of three classnames, then calls the C<.run> method on each, in parallel, and returns a disjunction of the results of

Re: String concatentation operator

2002-11-17 Thread Damian Conway
Dan Sugalski wrote: Creates a disjunction of three classnames, then calls the C<.run> method on each, in parallel, and returns a disjunction of the results >> of the calls (which, in the void context is ignored, or maybe >> optimized away). I was afraid you'd say that. Then you shouldn't ha

Re: Unifying invocant and topic naming syntax

2002-11-17 Thread Damian Conway
Adam D. Lopresto wrote: It seems like that would be useful and common enough to write as sub bar(;$foo is given) { ... } Where $foo would then take on the caller's topic unless it was explicitly passed an argument. While I can certainly see the utility of that, I believe it is too c

Re: String concatentation operator

2002-11-17 Thread Luke Palmer
> Date: Mon, 18 Nov 2002 07:39:55 +1100 > From: Damian Conway <[EMAIL PROTECTED]> > > It would be *vastly* better thought integrate junctive calls with > the standard threading behaviour. Of course, there will be a pragma or something to instruct it to operate serially, yes? Luke

Re: String concatentation operator

2002-11-17 Thread Damian Conway
Luke Palmer asked: Of course, there will be a pragma or something to instruct it to operate serially, yes? I doubt it. Unless there's a pragma to instruct threads to operate serially. In any case, I'm not sure what such a pragma would buy you. The ordering of evaluation would still be inherent

Re: Continuations

2002-11-17 Thread Damian Conway
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 {

Re: Continuations

2002-11-17 Thread Damian Conway
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:

Re: Continuations

2002-11-17 Thread Luke Palmer
> 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,

Re: Unifying invocant and topic naming syntax

2002-11-17 Thread Adam D. Lopresto
> > My favorite was from ages ago: > > > > sub bar(;$foo //= $_) {...} > > I think that today that would be written more like this: > > sub bar(;$foo) is given($def_foo) { > $foo = $def_foo unless exists $foo; > ... > } > > Though we might get away wi

Re: Continuations

2002-11-17 Thread Damian Conway
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 "

Re: String concatentation operator

2002-11-17 Thread Dan Sugalski
At 7:39 AM +1100 11/18/02, Damian Conway wrote: Dan Sugalski wrote: Creates a disjunction of three classnames, then calls the C<.run> method on each, in parallel, and returns a disjunction of the results of the calls (which, in the void context is ignored, or maybe optimized away). I was afr

Re: String concatentation operator

2002-11-17 Thread Iain 'Spoon' Truskett
* Dan Sugalski ([EMAIL PROTECTED]) [18 Nov 2002 12:56]: [...] > Perl's standard threading behaviour's going to be > rather heavyweight, though. Silly question time: Why is it going to be rather heavyweight? (Not complaining or berating, just wanting information =) ) > (Though the presentation on

Re: String concatentation operator

2002-11-17 Thread Dan Sugalski
At 1:00 PM +1100 11/18/02, Iain 'Spoon' Truskett wrote: * Dan Sugalski ([EMAIL PROTECTED]) [18 Nov 2002 12:56]: [...] Perl's standard threading behaviour's going to be rather heavyweight, though. Silly question time: Why is it going to be rather heavyweight? (Not complaining or berating, jus

Re: String concatentation operator

2002-11-17 Thread Dan Sugalski
At 8:22 AM +1100 11/18/02, Damian Conway wrote: Luke Palmer asked: Of course, there will be a pragma or something to instruct it to operate serially, yes? I doubt it. Unless there's a pragma to instruct threads to operate serially. In any case, I'm not sure what such a pragma would buy you. T