Here is a suggestion for Perl's branding:
http://nigelhamilton.com/perl-branding-proposal.html
SixFix is a weekly email with something new to learn about Perl 6. But there's
a catch! Each email includes a coding challenge and a question about Perl 6
you must answer to receive your next SixFix.
SixFix helps you learn Perl 6 with practical coding exercises (approx 1/2
an hour each week). You
I like the Camelia it's colourful, fun - it even has an embedded, sideways
reference to a Camel.
But IMHO there is a need for three logos:
1. Combined Parrot + Rakudo
I like the suggestion of having cartoon speech bubbles around the Parrot
that contain favicons of the language icons (e.g.,
But IMHO there is a need for three logos:
1. Combined Parrot + Rakudo
(Parrot with speech bubbles in favicon halo)++
2. Rakudo
Camelia++
3. Perl6 = the test suite
The current plan is that Perl6 will not have a single implementation but
that the test suite is shared by
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 course just be stored in RAM like the
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
And handling user errors in a GUI application is a task for event handling,
*not* exception handling. I agree that both mechanisms share large parts
of the infra-structure supporting them. But I make a strong conceptual
distinction between them.
Which leads to the question, does Perl6 have or
What about . for each level up you want to go?
instead of 1.say, 2.say, 3.say
you use .say, ..say, ...say
(Ok, I'm just kidding.. really!)
I read your message after I suggested the same thing (I'm too impatient
to read all new messages before sending replies).
Why were you just kidding? I think
On Thu, Mar 17, 2005 at 03:59:43PM -0800, Michael G Schwern wrote:
: What it doesn't solve is the $.method vs .method issue. They look
similar
: but one works on the invocant and one works on $_. Still a trap.
Yes, and that's probably the killer of the oc idea. So much for
Sleep Brain, heh,
I agree. I think the biggest mistake Perl 6's documentation system
could make is to make it Javadoc-style automatic. This is one of those
weird, backwards, cultural decisions, where we actually want to make the
programmer's life a little harder.
When I (seldomly) progam in Java, I find it very
: Given this Pugs program, t.p6:
:
: my $fh = open(@ARGS[0]);
: my @lines = =$fh;
: $fh.close();
: for @lines { print$_ }
:
: running:
:
: pugs t.p6 t.p6
:
: produces no output. Move $fh.close() to after the for
: loop and all is well. Is this a bug?
I wonder if IO::All could provide some
11 matches
Mail list logo
