Joe Gottman wrote:
Since a FIRST block gets called at loop initialization time, it seems to me
that it would be useful to have a block closure trait, RESUME, that gets
called at the beginning of every loop iteration except the first. Thus, at
the beginning of each loop iteration either FIRST or
Damian (), Ruud (), Damian (), Carl ():
But it can hardly be blamed for clarity.
That's a little unfair.
can hardly be blamed - can easily be praised g
Apologies to Carl if I misinterpreted. I read it as:
can hardly be blamed for (having) clarity
;-)
No, yours is the correct
On 8/30/06, Jonathan Lang [EMAIL PROTECTED] wrote:
Joe Gottman wrote:
Since a FIRST block gets called at loop initialization time, it seems to
me
that it would be useful to have a block closure trait, RESUME, that gets
called at the beginning of every loop iteration except the first. Thus,
On Tue, Aug 29, 2006 at 19:49:38 -0500, Mark Stosberg wrote:
I'm interested in helping to write some tests for return types, but
I'd like some clarifications about them first. Are they just
declarations that help Perl optimize stuff, or they actually contracts?
'of' is the contractual form,
On Tuesday 29 August 2006 19:51, Matt Diephouse wrote:
It's been said that writing PMCs sucks. This is your chance to tell
the world why. Because for things to get better, we have to know what
sucks.
I'll get things started:
1) pmc2c.pl is very fragile - when it gets input it doesn't
Damian Conway schreef:
[for @array - $index, $value {...}]
No. There's no such magic. I simply screwed up. I should have written:
for @array.kv - $index, $value {...}
:-(
Ah, much clearer now. g
--
Affijn, Ruud
Gewoon is een tijger.
Since nobody else has answered yet, I'll try to say something.
I'll post this also to perl6-language so that those who know better
can comment on this.
On 8/28/06, Mark Stosberg [EMAIL PROTECTED] wrote:
First, what's the recommended reference for learning how dispatching to
the right 'multi'
In a message dated Tue, 29 Aug 2006, Mark Stosberg writes:
my $rm = sub { given $rm_param {
when Code { $rm_param(self) }
when Hash { %rm_paramrun_mode }
default{ self.query.param($rm_param) }
}}();
This is eerily like Contextual::Return, which made me wonder if
Matt Diephouse wrote:
Joshua Juran [EMAIL PROTECTED] wrote:
On Aug 28, 2006, at 12:18 PM, Matt Diephouse wrote:
I would like to add some sort methods as well: quicksort(),
mergesort(), etc. But as methods, there is potential for these to end
up in a user-visible space.
Say for example,
All,
This email is part of a brain dump from my thoughts over the last
week while I was away from a computer. If anything doesn't make
sense, I will clarify or expand it in the following days.
I believe that Perl 6 already has basically all of the necessary
parts built-in for implementing
HI Darren,
Generally I really like the idea of fixing the relational/OO
mismatch problem by swallowing the relational model whole. :-)
But I wonder if we are ready to say goodbye to the tyranny of disk
seek? How will your proposed system use the disk? And if it does use the
disk what
Agent Zhang wrote:
According to S04, given {} is at statement level, so you can't use it
directly as an expression. But Perl 6 always allow you to say
my $foo = do given {...}
As well as
my $foo = do if foo {...} else {...}
I confirmed this both work now with pugs!
I think the
Jeff Stampes [EMAIL PROTECTED] writes:
My bigger concern with the Perl6 syntax is that they expect humans
to write it. This is a similar problem that Forth and Lisp had.
You see how widely used those are now...
It will always be difficult to compare Perl X against any other
language. Perl5
On Wednesday 30 August 2006 04:12, Watson Ladd wrote:
Seriously, what's so bad about adding functionality into
a language?
I once saw an overfilled waterbed that was almost as tall as I am. I would
have called it PHP, but it didn't explode and throw cold water all over the
house.
-- c
Currently compilation fails on OS X with gcc/g++, because -bundle as the
first argument gets interpreted as a request to run the undle version of
the compiler. It works fine as a later argument, so there's no need to
break compatibility with the Apple compiler:
Index:
What version of OSX and gcc are you using? I haven't seen this
problem on 10.4.7 PPC with gcc 4.0.1.
Did it just break recently??
Not that I see any problem applying this patch, regardless.
On Aug 30, 2006, at 4:55 PM, Mark J. Reed wrote:
Currently compilation fails on OS X with gcc/g++,
Whups, sorry, I meant to say OS X 10.3, with its gcc (3.3). I agree that
it seems to build fine on Tiger.
On 8/30/06, Will Coleda [EMAIL PROTECTED] wrote:
What version of OSX and gcc are you using? I haven't seen this
problem on 10.4.7 PPC with gcc 4.0.1.
Did it just break recently??
Not
I told my coworkers I'd get pugs up and running for us, so we could
start getting some hands on experience. I managed this on my home
system in the past, but am completely stymied now.
We're running Red Hat Enterprise 4, and I'm stuck at square one, trying
to get GHC running. You need ghc
Jeff Stampes [EMAIL PROTECTED] writes:
We're running Red Hat Enterprise 4, and I'm stuck at square one,
trying to get GHC running. You need ghc working to compile ghc, or
you need to bootstrap it.
Did you already try one of the binaries from
http://www.haskell.org/ghc/download_ghc_641.html
Thanks to Steffen and others who sent me some help and words of
encouragement...I believe I have it working now :)
Trey Harris asked:
This is eerily like Contextual::Return, which made me wonder if it's
even required in Perl 6.
Obviously we can do
return do given want {
when :($) { ... }
...
};
But return do given want flows so badly, I desperately want some sugar
On Wed, 30 Aug 2006, Nigel Hamilton wrote:
HI Darren,
Generally I really like the idea of fixing the relational/OO
mismatch problem by swallowing the relational model whole. :-)
But I wonder if we are ready to say goodbye to the tyranny of disk
seek? How will your proposed
My bigger concern with the Perl6 syntax is that they expect humans to
write it. This is a similar problem that Forth and Lisp had. You see
how widely used those are now...
...
How would you respond?
I would expose and challenge the presumptions in the statement.
My bigger concern... Do
Thank you Martin, and everyone else. We've had several other
conversations, and I believe this boils down to just a natural
pessimist. She wants to see perl continue to be a widely adopted
successful language, and while she is willing to do whatever work it
takes to learn, she doesn't have
On 8/30/06, chromatic [EMAIL PROTECTED] wrote:
On Wednesday 30 August 2006 04:12, Watson Ladd wrote:
Seriously, what's so bad about adding functionality into
a language?
I once saw an overfilled waterbed that was almost as tall as I am. I would
have called it PHP, but it didn't explode and
On 8/30/06, Luke Palmer [EMAIL PROTECTED] wrote:
The problem with PHP is not that it has
too much functionality, but that it is organized extremely poorly.
Amen. PHP is the poster child for namespace pollution. And PHP5 actually
has the tools to stop the madness; it's just a question of
On 8/31/06, Mark J. Reed [EMAIL PROTECTED] wrote:
On 8/30/06, Luke Palmer [EMAIL PROTECTED] wrote:
The problem with PHP is not that it has
too much functionality, but that it is organized extremely poorly.
Amen. PHP is the poster child for namespace pollution. And PHP5 actually
has the
At 5:31 AM +0100 8/31/06, Nigel Hamilton wrote:
Rather, the proposal is focusing on what users of these data structures
would / could see. The idea is that relational structures have the same
ease of use and flexability that things like hashes or arrays or sequences
or sets do now. They can of
28 matches
Mail list logo
