> Here is a suggestion for Perl's branding:
>>
>> http://nigelhamilton.com/perl-branding-proposal.html
>>
>
> I like your proposal.
>
>
:-)
> But its details would need fleshing out more, particularly at the end,
> where it says this:
>
> Perl $new_runtime_name_for_perl5_goes_here (tm)
> Perl
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
As Plumhead is a stupid name, cotto proposed to rename to Pharrot.
So I'm still open for an alternative.
Parroheep?
IMHO the name needs to be distinctive from parrot - pharrot is a little too
close.
What about taking the idea from Space Odyssey where they derived the name
for the HAL
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
I've been reading the Perl6 type and method dispatch discussions with
some fear and trepidation.
Just following the linear flow of control through a program can sometimes
be a mind bend. The type inferencing and dispatch system for Perl6 seems
very funky. Throw in some autothreading and
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,
All that said I think a per-module perldoc documentation reader is
still very important too ... maybe your design could allow for traversable
HTML conversion in the future?
Well my idea is to not dictate the eventual output. But to create a system
which allows the most
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
Hi Steven,
I think one of the great features of JavaDoc is the ability to
generate hyperlinked documentation - so someone can walk the
inheritance/interface hierarchy within their browser. It also provides
consistency across all Java packages.
For things like MMD --- I'd like to traverse the
16 matches
Mail list logo
