On Mon, Mar 31, 2003 at 10:56:14AM +0200, Matthijs van Duin wrote:
temp $foo := $bar; # temporarily bind $foo to $bar
temp $foo = $bar;# temporarily assign the value of $bar to $foo
I just realize 'temp $foo = 3' might just as well mean bind $foo to a new
scalar and initialize it to 3
Okay,
I've been thinking about closures, continuations, and coroutines, and
one of the interfering points has been threads.
What's the P6 thread model going to be?
As I see it, parrot gives us the opportunity to implement preemptive
threading at the VM level, even if it's not available via the
On Monday, March 31, 2003, at 07:39 AM, Piers Cawley wrote:
Argument initializations
Michael Lazzaro summarized the various different and proposed
assignment
operators available in Perl 6, including a proposed ::= for 'only
assign to uninitialized variables'. Michael wondered how
On Mon, Mar 31, 2003 at 07:45:30AM -0800, Austin Hastings wrote:
I've been thinking about closures, continuations, and coroutines, and
one of the interfering points has been threads.
What's the P6 thread model going to be?
As I see it, parrot gives us the opportunity to implement preemptive
On Mon, Mar 31, 2003 at 10:09:43AM -0800, Michael Lazzaro wrote:
I'm still hoping rather desperately for a if-uninitialized op in
general, even if only for hashes, because the difference between
present but undefined and not present is rather crucial for some
common algorithms.
Can you
[EMAIL PROTECTED] (Matthijs Van Duin) writes:
I think if we apply the Huffman principle here by optimizing for the
most common case, cooperative threading wins from preemptive threading.
Well, if you optimize for the most common case, throw out threads altogether.
--
The bad reputation UNIX
On Monday, March 31, 2003, at 10:15 AM, Jonathan Scott Duff wrote:
On Mon, Mar 31, 2003 at 10:09:43AM -0800, Michael Lazzaro wrote:
I'm still hoping rather desperately for a if-uninitialized op in
general, even if only for hashes, because the difference between
present but undefined and not
On Mon, Mar 31, 2003 at 08:13:09PM +0200, Matthijs van Duin wrote:
I think we should consider cooperative threading, implemented using
continuations. Yielding to another thread would automatically happen when
a thread blocks, or upon explicit request by the programmer.
It has many
Piers Cawley writes:
is static?
Discussion of static/state variables continued. Arcadi Shehter wondered
if it made sense to attach but properties to closures. I confess I
didn't really understand what he was driving at. Austin Hastings and
Actually, I was confused , thinking
--- Dan Sugalski [EMAIL PROTECTED] wrote:
At 8:13 PM +0200 3/31/03, Matthijs van Duin wrote:
On Mon, Mar 31, 2003 at 07:45:30AM -0800, Austin Hastings wrote:
I've been thinking about closures, continuations, and coroutines,
and
one of the interfering points has been threads.
What's the P6
On Mon, Mar 31, 2003 at 10:50:59AM -0800, Michael G Schwern wrote:
I must write my code so each operation only takes a small fraction of time
or I must try to predict when an operation will take a long time and yield
periodicly.
Really.. why? When you still have computation to be done before you
On Mon, Mar 31, 2003 at 11:04:35AM -0800, Michael Lazzaro wrote:
my bool $x = result_of_some_big_long_calculation(...args...);
return $x if $x;
Is there a way that doesn't require the named variable?
$_ and return given big_calculation();
or:
given big_calculation() {
return
On Mon, Mar 31, 2003 at 01:58:19PM -0500, Dan Sugalski wrote:
Dan doesn't like it. :)
Well, there are actually a lot of disadvantages, but that's the only
important one, so it's probably not worth much thought over alternate
threading schemes for Parrot at least--it's going with an OS-level
On Monday, March 31, 2003, at 11:18 AM, Matthijs van Duin wrote:
On Mon, Mar 31, 2003 at 11:04:35AM -0800, Michael Lazzaro wrote:
my bool $x = result_of_some_big_long_calculation(...args...);
return $x if $x;
Is there a way that doesn't require the named variable?
$_ and return given
On Mon, Mar 31, 2003 at 12:12:54PM -0800, Michael Lazzaro wrote:
Don't those return Cundef, as opposed to the value of C$_? I.E.
wouldn't it be:
$_ and return $_ given big_calculation();
-or-
given big_calculation() {
return $_ when true;
}
Personally I'd just
On Mon, Mar 31, 2003 at 11:58:01AM -0800, Michael G Schwern wrote:
Off-list since this tastes like it will rapidly spin out of control.
On-list since this is relevant for others participating in the discussion
Classic scenario for threading: GUI. GUI uses my module which hasn't been
carefully
On Mon, Mar 31, 2003 at 12:12:54PM -0800, Michael Lazzaro wrote:
On Monday, March 31, 2003, at 11:18 AM, Matthijs van Duin wrote:
Don't those return Cundef, as opposed to the value of C$_? I.E.
wouldn't it be:
$_ and return $_ given big_calculation();
-or-
given big_calculation() {
--- Jonathan Scott Duff [EMAIL PROTECTED] wrote:
On Mon, Mar 31, 2003 at 12:12:54PM -0800, Michael Lazzaro wrote:
Don't those return Cundef, as opposed to the value of C$_?
I.E. wouldn't it be:
$_ and return $_ given big_calculation();
-or-
given big_calculation() {
On Mon, Mar 31, 2003 at 07:21:03PM +0100, Simon Cozens wrote:
[EMAIL PROTECTED] (Matthijs Van Duin) writes:
I think if we apply the Huffman principle here by optimizing for the
most common case, cooperative threading wins from preemptive threading.
Well, if you optimize for the most common case,
Michael Lazzaro writes:
Forgive me; a very minor style efficiency question... what would the
canonical way to do this be, given what we know of Perl6?
# the hapless, inefficient version:
return result_of_some_big_long_calculation(...args...)
if
On Monday, March 31, 2003, at 11:21 AM, Smylers wrote:
Michael Lazzaro writes:
Forgive me; a very minor style efficiency question... what would the
canonical way to do this be, given what we know of Perl6?
# the hapless, inefficient version:
return
On Mon, Mar 31, 2003 at 02:58:12PM -0800, Michael Lazzaro wrote:
my $x = baz(...args...);
return $x if $x;
I'm looking for a Perl6 way to say that oft-repeated, oft-chained
two-line snippet up there without declaring the temporary variable.
Using Cgiven or Cwhen, maybe?
$_ and return $_
Matthijs van Duin wrote:
On Mon, Mar 31, 2003 at 02:58:12PM -0800, Michael Lazzaro wrote:
my $x = baz(...args...);
return $x if $x;
I'm looking for a Perl6 way to say that oft-repeated, oft-chained
two-line snippet up there without declaring the temporary variable.
Using Cgiven or
On Tue, Apr 01, 2003 at 09:25:39AM +1000, Damian Conway wrote:
baz does refer to the Code object itself, as you say.
However, the bar(...) syntax *will* DWYM too. That's because:
baz(@args);
is just a shorthand for:
baz.(@args);
That's not what page 5 of Apoc 6 says:
quote
Note that when
On Monday, March 31, 2003, at 12:30 PM, Paul wrote:
I started to suggest this myself, then realized that you might not want
it to return at all if the value is false.
Yes, exactly:
sub foo(...args...) {
# We first attempt to get our return value the easy way.
# If
Since my mail server has been down for a week, I've had a lot of time
to look through Perl 6 as it stands, without being concerned with
current issues. I'll do them one-message-at-a-time (and rather
slowly, too).
The first thing I noticed was the == / eq distinction. This has been
invaluable
While my last post was about removing entities, this one will be about
adding them.
Now, I don't know what Larry has up his sleeve in this respect, but as
I see it now, Cis is too heavily overloaded. As it stands, it means
3 things:
(1) Attributing traits
(2) Inheriting base classes
Matthijs van Duin wrote:
That's not what page 5 of Apoc 6 says:
Wow, I guess I should read those things, eh? ;-)
Thanks for correcting my mistake, Matthijs.
Damian
The Perl 6 Summary for the week ending 20030330
Welcome once again to the gallimaufry that is a Perl 6 summary.
Unfettered this week by the presence of feline distraction we plunge
straight into the crystal clear waters of perk6-internals.
Iterator proof of concept
People must
At 8:13 PM +0200 3/31/03, Matthijs van Duin wrote:
On Mon, Mar 31, 2003 at 07:45:30AM -0800, Austin Hastings wrote:
I've been thinking about closures, continuations, and coroutines, and
one of the interfering points has been threads.
What's the P6 thread model going to be?
As I see it, parrot
Forgive me; a very minor style efficiency question... what would the
canonical way to do this be, given what we know of Perl6?
# the hapless, inefficient version:
...
return result_of_some_big_long_calculation(...args...)
if result_of_some_big_long_calculation(...args...);
31 matches
Mail list logo
