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
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
* 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
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
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 "
> > 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
> 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 {
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
> 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
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
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
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
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
16 matches
Mail list logo
