On Tue, 18 Jun 2002, Robert Spier wrote:
> May I suggest requiring any non-trivial patches to contain:
> - the patch
> - a test
> - a human readable changelog entry
+1!
cvs log exports are rarely useful.
Usually they go
"had problems with $baz so we changed $xfoo to $zfoo
to
On Mon, 2002-06-17 at 16:10, Luke Palmer wrote:
> > So, in order for me to avoid learning Java, I propose
> > that a CPAN "Curation Project", or an Extended
> > Standard Perl Library", be formed.
>
> Or, Standard Extended Library of Perl. SELP is more pronouncable than
> ESPL. SELF is bette
At 02:10 PM 6/17/2002 -0600, Luke Palmer wrote:
>Java's hell if you know Perl. You're used to doing things in 200
>keystrokes, and suddenly it takes you 5000. "The easy things should be
>long, and the hard things should be longer... and slower." (i.e. I don't
>like Java)
If you don't have the b
On Mon, Jun 17, 2002 at 03:43:48PM -0400, Melvin Smith wrote:
> Ok, then we should start some nitty-gritty talk. I'm familiar with
> implementing parsers for LR(1) grammars. I hope Larry, and other
> people that have been digesting the Apocalypses (I can't say I have)
> can fill us in about the ch
Hey stop bad mouthing macros :)
5's problems with macros is not that there are so many of them, but that documentation
and usage guidelines are hard to come by. The lesson, for Parrot developers to learn
from 5's macros, is that both macros and functions, the entire internal API, must
be doc
Melvin's quip regarding macros, while harmless in itself, is, I fear, a symptom
of a real problem. One of the muses for parrot and perl 6 has always been
the inaccessibilty of the perl 5 code base. Perl 5's reliance upon
macros has been cited often as a source of confusion, by those attempting
At 06:55 PM 6/18/2002 +0200, Bart Schuller wrote:
>On Mon, Jun 17, 2002 at 03:43:48PM -0400, Melvin Smith wrote:
> > Ok, then we should start some nitty-gritty talk. I'm familiar with
> > implementing parsers for LR(1) grammars. I hope Larry, and other
> > people that have been digesting the Apoca
At 12:47 AM 6/18/2002 -0400, David J. Goehrig wrote:
>Melvin's quip regarding macros, while harmless in itself, is, I fear, a
>symptom
>of a real problem. One of the muses for parrot and perl 6 has always been
I have no fear of macros; I contributed quite a few to Parrot myself. :)
>Perl 5's p
On Tue, 18 Jun 2002, Melvin Smith wrote:
: 2) In fact, there are MANY funny named macros in Perl5.
That is precisely *why* they had to have funny names. Perl 5's
macro naming schemes were a vast improvement over Perl 4's. In
Perl 4 it was impossible to tell at a glance what kind of macro
you we
On Mon, Jun 17, 2002 at 04:59:05PM -0400, Melvin Smith wrote:
> The hole I see is not having a Perl6 grammar to toss about.
> You must sift through the apoc/exe pile to formulate it. Regardless of
> which approach is taken, I'd like to see a BNF style grammar floating around
> before we talk tools
At 11:49 AM 6/18/2002 -0700, Larry Wall wrote:
>On Tue, 18 Jun 2002, Melvin Smith wrote:
>: 2) In fact, there are MANY funny named macros in Perl5.
>
>That is precisely *why* they had to have funny names. Perl 5's
>macro naming schemes were a vast improvement over Perl 4's. In
>Perl 4 it was imp
On Tue, 18 Jun 2002, Jerome Vouillon wrote:
> On Mon, Jun 17, 2002 at 04:59:05PM -0400, Melvin Smith wrote:
> > The hole I see is not having a Perl6 grammar to toss about.
> > You must sift through the apoc/exe pile to formulate it. Regardless of
> > which approach is taken, I'd like to see a BNF
Okay, here are some tasks for the interested. They're all related (I
expect you'll see the pattern), but independent anyway.
1) Dig through the perl source and find out all the opcodes. (pp.c
and friends) Document the opcodes and what they do.
2) The same as #1, only for Python
3) The same as
# New Ticket Created by "Clinton A. Pierce"
# Please include the string: [netlabs #716]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=716 >
Background:
String variables in BASIC are stored in the P21 PMC. When I ty t
Dan Sugalski wrote in perl.perl6.internals :
> Okay, here are some tasks for the interested. They're all related (I
> expect you'll see the pattern), but independent anyway.
>
> 1) Dig through the perl source and find out all the opcodes. (pp.c
> and friends) Document the opcodes and what they
>Date: Tue, 18 Jun 2002 15:55:51 -0500
>From: Joe Mason
>To: Dan Sugalski <[EMAIL PROTECTED]>
>Subject: Re: Tasks for the interested
>
>
>On Tue, Jun 18, 2002 at 04:33:55PM -0400, Dan Sugalski wrote:
>> Okay, here are some tasks for the interested. They're all related (I
>> expect you'll see the
So now who's going to implement it? (must..contain..urge..)
--Josh
At 17:03 on 06/18/2002 EDT, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >> 6) Infocom's z-machine
> >
> >http://www.gnelson.demon.co.uk/zspec/sect14.html
>
> Well, that's one...
At 5:10 PM -0400 6/18/02, Josh Wilmes wrote:
>So now who's going to implement it? (must..contain..urge..)
You think *you* have to contain the urge... :)
Seriously, this is a good thing to tackle. Not only does it involve
custom opcode libraries, but it also requires packfile loading with
tran
Oh man.
Now i'm doomed. I guess i'll start playing tonight then ;-)
--Josh
At 17:20 on 06/18/2002 EDT, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 5:10 PM -0400 6/18/02, Josh Wilmes wrote:
> >So now who's going to implement it? (must..contain..urge..)
>
> You think *you* have to contain t
Larry has previously mentioned the prospect of Perl 6 module names being extended to
include version number and author.
If this were to be done, would seem reasonable for the "author" component to simply be
the author's CPAN username. These are guaranteed unique, are frequently mnemonic, are
n
Larry has previously mentioned the prospect of Perl 6 module names being extended to
include version number and author.
If this were to be done, would seem reasonable for the "author" component to simply be
the author's CPAN username. These are guaranteed unique, are frequently mnemonic, are
n
Okay, folks, just a heads up. I'm going to be mostly without internet
access until early next week--first it's off to Arizona, then to St
Louis, and I don't expect much in the way of connectivity until late
next monday at the earliest, so...
If everyone'd be nice to the folks coming over to wo
On 6/18/02 6:10 PM, Damian Conway wrote:
> Larry has previously mentioned the prospect of Perl 6 module names being
> extended to include version number and author.
>
> If this were to be done, would seem reasonable for the "author" component to
> simply be the author's CPAN username. These are g
At 09:29 PM 6/18/2002 +0200, Jerome Vouillon wrote:
>On Mon, Jun 17, 2002 at 04:59:05PM -0400, Melvin Smith wrote:
>I have started writing a Perl 6 grammar:
> http://www.pps.jussieu.fr/~vouillon/parrot/parser.y
>It is far from complete, and certainly not very accurate, but it may
>be a good st
On Tue, 18 Jun 2002, John Siracusa wrote:
: On 6/18/02 6:10 PM, Damian Conway wrote:
: > Larry has previously mentioned the prospect of Perl 6 module names being
: > extended to include version number and author.
: >
: > If this were to be done, would seem reasonable for the "author" component to
On 6/18/02 8:32 PM, Larry Wall wrote:
> I expect to end up with a multi-level system, where you can use anything from
> a DNS name (guaranteed to contain dots) through author IDs (no dots) to
> blessed top-level names for universally acclaimed modules, for some definition
> of universal.
I'm not
Based on perlop(1) and the note at the end of apocalypse 3, here's a start
on a Parse::RecDescent grammar for Perl 6 expressions. It does not handle
some variables; in particular, qq/${"foo"}/ won't fly. It should handle
precedence and hyping when adding new operators in the "right way". To
add
27 matches
Mail list logo
