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
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
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
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
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
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...
>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
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
# 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
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
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
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 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
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
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
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
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
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
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
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
20 matches
Mail list logo
