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
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, C is too heavily overloaded. As it stands, it means
3 things:
(1) Attributing traits
(2) Inheriting base classes
(3
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 f
> 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.
> #
All~
I just checked out a fresh copy of the everything and got
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t/op/hacks.t 1 256 91 11.11% 7
t/src/basic.t255 65280 22 100.0
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:
Note that when foll
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 C or C, maybe
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 C or C, maybe?
$_ and return $_ given ba
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 &result_of_some_big_long_calculation(
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 &result_of_some_b
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, th
Alberto Sim?es/EPL sent the following bits through the ether:
> Anybody can tell me the address for RT/perl software?
http://rt.perl.org/ is what you should be using to submit bugs (and
patches!)
HTH, Leon
ps it runs http://www.bestpractical.com/rt/
--
Leon Brocard.
On Mon, Mar 31, 2003 at 12:54:38PM +0100, Alberto Simões/EPL wrote:
> Anybody can tell me the address for RT/perl software?
> Thanks a lot.
Go to google.com, type in RT, hit "I'm feeling lucky"
--
It wasn't false, just differently truthful.
-- Abhijit Menon-Sen in <[EMAIL PROTECTED]>
--- Jonathan Scott Duff <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 31, 2003 at 12:12:54PM -0800, Michael Lazzaro wrote:
> > Don't those return C, as opposed to the value of C<$_>?
> > I.E. wouldn't it be:
> >
> > $_ and return $_ given big_calculation();
> > -or-
> > given big_calculatio
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 C, 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 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 wr
On Mon, Mar 31, 2003 at 12:12:54PM -0800, Michael Lazzaro wrote:
> Don't those return C, 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 ju
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 big
On Mon, Mar 31, 2003 at 10:50:59AM -0800, Michael G Schwern wrote:
> 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 thre
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
pre
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 whe
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 c
--- 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.
> >>
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 , thi
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...);
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 give
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 adv
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 pr
[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 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.
Ca
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
thread
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
At 7:20 PM +0200 3/30/03, Juergen Boemmels wrote:
Dan Sugalski <[EMAIL PROTECTED]> writes:
At 12:59 AM + 3/23/03, "Jürgen" "Bömmels" (via RT) wrote:
>Yet another step in PIO:
>Enabling read buffering.
A test with this starts throwing errors at t/src/list and goes on from
there--lots of do
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 O
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 re
On Mon, Mar 31, 2003 at 02:44:57PM +0100, Alberto Simões/EPL wrote:
> On Mon, Mar 31, 2003 at 04:04:53AM -0800, Michael G Schwern wrote:
> | On Mon, Mar 31, 2003 at 12:54:38PM +0100, Alberto Simões/EPL wrote:
> | > Anybody can tell me the address for RT/perl software?
> | > Thanks a lot.
> |
> | G
On Mon, Mar 31, 2003 at 04:04:53AM -0800, Michael G Schwern wrote:
| On Mon, Mar 31, 2003 at 12:54:38PM +0100, Alberto Simões/EPL wrote:
| > Anybody can tell me the address for RT/perl software?
| > Thanks a lot.
|
| Go to google.com, type in RT, hit "I'm feeling lucky"
I tried RT/Perl and my ans
Hello,
I read in the vtables.pod document that is possible to create a non-built-in PMC. I
assume this is to have the possibility to easily extend the runtime environment,
without recompiling the VM. So, some developer can
create some extending PMCs and use those in its source (parrot asm or im
Anybody can tell me the address for RT/perl software?
Thanks a lot.
alberto
--
Departamento de Informatica - Universidade do Minho
"The C Programming Language -- A language which combines the
flexibility of assembly language with the power of assembly language."
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
Just checking.. will 'temp' temporize the container (like it does in perl 5)
or the value? Both have their pros and cons and could be useful.
Or will it depend on how the temp is used, like:
temp $foo := $bar; # temporarily bind $foo to $bar
temp $foo = $bar;# temporarily assign the
41 matches
Mail list logo
