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 Cyield than suspended it. *And* that Cyield returns the new argument list with which it was resumed. So you can write

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 Cyield than suspended it. *And* that Cyield returns the new argument list with which it was

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 have

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

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

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, no less),

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 with:

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 Now

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

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,

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.