When #39930 is resolved, we can eliminate the workaround.
After applying a patch to #39930 in r29301, deleted this workaround in r29304
--
Salu2
Closing ticket
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #50092]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=50092
This is a placeholder ticket so we can show a dependency on #39930.
In the
Is it possible to compile a single PGE grammar against multiple sets
of actions to get multiple different parsers? This would be good for
Lisp-like languages where you have one parser that spits out PIR code
and a parser that is invoked for (read) calls and spits out
s-expression objects. Both
On Tue, Dec 04, 2007 at 12:54:43PM -0500, istarex wrote:
Is it possible to compile a single PGE grammar against multiple sets
of actions to get multiple different parsers? This would be good for
Lisp-like languages where you have one parser that spits out PIR code
and a parser that is invoked
processing by the Tree Grammar Engine(TGE) compiler tool, the
pastrule attribute can be used to specify custom TGE processing.
Colin Kuskie wrote:
# New Ticket Created by Colin Kuskie
# Please include the string: [perl #44489]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44489
A - an before vowels.
Apostrophes missing in possessives.
Resolved in r20551.
hi,
attached my current version of languages/pynie's grammar.
I can't get the binary operators is not and not in working
correctly. The problem seems to be that is parsed() does not work.
When I specify a rule in the is parsed() annotation, and in the rule I
emit some message (just calling
hi,
attached an updated grammar for pynie/python. The PAST stuff is still
broken, have to work a bit on that.
THis grammar does part of the expression parsing recursive descent, and
from comparisons (==, != etc) to the power operator (**) through the
operator table.
regards,
kjs
## $Id
hi,
attached a patch that adds the last few bits of the Python grammar.
Please note that there may be bugs, but I put in all rules, (not using
the optable, that one is commented out)
I had to put some things into comments in the ASTgrammar, the expression
stuff needs work.
I removed
tomorrow.
regards,
kjs
## $Id: grammar_rules.pg 17096 2007-02-20 20:20:48Z paultcochrane $
## TITLE
## Pynie::Grammar -- a grammar for parsing Python
##
## DESCRIPTION
##
## These are a set of rules for parsing programs written in Python.
## Many of the rules are derived from the Python
hi,
attached a patch for the Lua grammar file for PGE (lua.pg).
fixing:
* reorganized some rules w.r.t. do block end
* varargs rule instead of ...
* fixed table constructor rules (they now work correctly) -- stolen from
lua51.pg
regards,
kjs
Index: languages/lua/src/lua.pg
hi,
attached a patch for the PGE implementation of the Lua parser (lua.pg).
fixing:
* make name rule match longest identifiers, not keyword-prefixed
identifiers (like for in format)
* fix parameter list rule
* all examples in the lua distribution (in the test directory) can be
parsed
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #40688]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40688
From the file languages/tcl/src/grammar/expr/expression.pg:
# XXX This began
/grammar/expr/past2pir.tg
This ticket is in response to cage task #39704.
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #40691]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40691
Determine if goto statement is needed in
languages/tcl/src/grammar/expr
# New Ticket Created by Nuno Carvalho
# Please include the string: [perl #40160]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40160
Good afternoon,
After some more discussion on #parrot I've rewrote a very
# New Ticket Created by Nuno Carvalho
# Please include the string: [perl #40187]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40187
Good morning,
After some more discussion on #parrot I've rewrote a very simple
Hi
Ignore close this one i guess, everyone thought this mail was lost.
./smash
On 8/17/06, via RT Nuno Carvalho [EMAIL PROTECTED] wrote:
# New Ticket Created by Nuno Carvalho
# Please include the string: [perl #40160]
# in the subject line of all future correspondence about this issue.
#
On Thu, Aug 17, 2006 at 01:22:11AM -0700, Nuno Carvalho wrote:
After some more discussion on #parrot I've rewrote a very simple
test file to evaluate some very simple PGE grammars. [...]
Applied, thanks!
Pm
-grammar.t
=head1 DESCRIPTION
@@ -24,55 +23,53 @@
my $SUB = 'SUB';
.sub _match_expr
-.param string grammar
-.param string expr
-.local pmc p6regex, code, parse, match
-load_bytecode 'PGE.pbc'
-load_bytecode 'compilers/pge/pgc.pir'
+ .param string
Good afternoon,
After some, always healthy, discussion on #parrot I've started a
very simple test file to evaluate some very simple PGE grammars. The
few grammars included in the test should work ok, except test #7 which
is supposed to fail with the current PGE. After the needed PGE
corrections
Hi
Today in #parrot a question was done:
rule foo { bar* }
should be considered:
rule foo { ?wsbar*?ws }
or
rule foo { ?ws(bar?ws)* }
?
Cheers
Alberto
--
Alberto Simões - Departamento de Informática - Universidade do Minho
Campus de Gualtar - 4710-057 Braga -
On Fri, Aug 11, 2006 at 04:43:55PM +0100, Alberto Simões wrote:
Hi
Today in #parrot a question was done:
rule foo { bar* }
should be considered:
rule foo { ?wsbar*?ws }
or
rule foo { ?ws(bar?ws)* }
In the past we've always gone with the former.
If bar is also a rule,
# New Ticket Created by Kevin Tew
# Please include the string: [perl #39854]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=39854
adds preamble section to tge grammar to allow for includes and global
defines
Kevin Tew (via RT) wrote:
adds preamble section to tge grammar to allow for includes and global
defines at the top of the PIR generated by TGE
For example, I use
preamble{
.include 'interpinfo.pasm'
}
You're on to an important idea, but it still needs refinement.
A bit of background
Hi
I am toying around with Parrot and the compiler tools. The documenation
of Perl 6 grammars that I have been able to find only describe rule. But
the grammars in Parrot 0.4.4 for punie and APL use rule, token and regex
elements.
Can someone please clarify the difference between these
On 6/2/06, Rene Hangstrup Møller [EMAIL PROTECTED] wrote:
Hi
I am toying around with Parrot and the compiler tools. The documenation
of Perl 6 grammars that I have been able to find only describe rule. But
the grammars in Parrot 0.4.4 for punie and APL use rule, token and regex
elements.
Can
On Fri, Jun 02, 2006 at 01:56:55PM -0700, jerry gay wrote:
On 6/2/06, Rene Hangstrup Møller [EMAIL PROTECTED] wrote:
I am toying around with Parrot and the compiler tools. The documenation
of Perl 6 grammars that I have been able to find only describe rule. But
the grammars in Parrot 0.4.4 for
# New Ticket Created by Joshua Hoblitt
# Please include the string: [perl #37244]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=37244
* Cleanup and straighten the grammar files
-J
--
# New Ticket Created by Will Coleda
# Please include the string: [perl #36424]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36424
The wonderful simple grammar that was demo'd at YAPC::NA via demo.pir should
Sven Schubert [EMAIL PROTECTED] wrote:
Hi all,
I am still working on PAPAgei - the PAscal for PArrot
compiler which is my final year project at I.T.
Carlow.
Hehe, good name.
However, I've been struggling with the basic task of
writing a PRD grammar for quite a while and am about
to turn
with a very basic grammar and gradually
extending it until it meets the full ISO standard.
However, I've been struggling with the basic task of
writing a PRD grammar for quite a while and am about
to turn to YAPP instead, if I can't get PRD to work
for me soon, as my project deadline is soon, _very_
soon
Andy Dougherty [EMAIL PROTECTED] writes:
--- parrot-orig/compilers/p6ge/p6ge_gen.c Fri Nov 19 08:53:40 2004
+++ parrot-andy/compilers/p6ge/p6ge_gen.c Fri Nov 19 14:43:43 2004
/* strcon(...) converts string values into PIR string constants */
static char*
-strcon(const char* s, int
On Fri, Nov 19, 2004 at 04:30:06PM -0500, Andy Dougherty wrote:
Ok, here's a first pass. Most of it is pretty straightforward, but one
thing is worth noting:
The code uses both signed and unsigned chars, with and without the 'const'
qualifier. I gather this is a deliberate part of a
On Sat, Nov 20, 2004 at 12:18:17AM +, Nicholas Clark wrote:
$ ../../parrot demo.pir
input /pattern, string to match, + to continue match, ? to print pir,
/
Unrecognized character at offset 1 (found '')
Segmentation fault
Is this a known limitation? [Done after Andy's patch went in]
On Sat, Nov 20, 2004 at 09:23:36AM +0100, Lars Balker Rasmussen wrote:
Andy Dougherty [EMAIL PROTECTED] writes:
/* strcon(...) converts string values into PIR string constants */
static char*
strcon(const char* s, int len)
Haven't looked at the code yet, but I'll just observe that
On Fri, 19 Nov 2004, Patrick R. Michaud wrote:
On Fri, Nov 19, 2004 at 04:30:06PM -0500, Andy Dougherty wrote:
Ok, here's a first pass. Most of it is pretty straightforward
One spot I may have goofed: I changed some initializations from to
NULL, which is, of course, rather a different
On Sat, Nov 20, 2004 at 10:46:03AM -0500, Andy Dougherty wrote:
On Fri, 19 Nov 2004, Patrick R. Michaud wrote:
On Fri, Nov 19, 2004 at 04:30:06PM -0500, Andy Dougherty wrote:
Ok, here's a first pass. Most of it is pretty straightforward
One spot I may have goofed: I changed some
I've just committed the first draft of a Perl 6 grammar engine to
the parrot repository (in compilers/p6ge). What you'll find there
is still at a somewhat early stage of development, I'm releasing it
now so that people can begin commenting and suggesting improvements
to the framework.
The next
On Fri, 19 Nov 2004, Dan Sugalski wrote:
So, if someone'd like to take a shot at thumping the template
makefile bits to add in compilers/p6ge to the basic build, that'd be
great. Grovelling over the code in there to scrub out portability
issues would also be good.
I'll take a look at this.
At 10:58 AM -0500 11/19/04, Andy Dougherty wrote:
On Fri, 19 Nov 2004, Dan Sugalski wrote:
So, if someone'd like to take a shot at thumping the template
makefile bits to add in compilers/p6ge to the basic build, that'd be
great. Grovelling over the code in there to scrub out portability
issues
On Fri, 19 Nov 2004, Andy Dougherty wrote:
On Fri, 19 Nov 2004, Dan Sugalski wrote:
So, if someone'd like to take a shot at thumping the template
makefile bits to add in compilers/p6ge to the basic build, that'd be
great. Grovelling over the code in there to scrub out portability
issues
On Thu, Nov 18, 2004 at 04:01:54PM -0700, Patrick R. Michaud wrote:
I've just committed the first draft of a Perl 6 grammar engine to
the parrot repository (in compilers/p6ge). What you'll find there
is still at a somewhat early stage of development, I'm releasing it
now so that people can
On Wed, Nov 17, 2004 at 10:35:47PM +, Nicholas Clark wrote:
On Wed, Nov 17, 2004 at 02:47:09PM -0700, Patrick R. Michaud wrote:
BTW, it may be very possible for me to write the p6ge generator so
that it can be switched between the PIR and bsr/ret calling conventions,
so we don't need
Dan Sugalski wrote:
[ this came up WRT calling conventions ]
I assume he's doing bsr/ret to get into and
out of the sub, which is going to be significantly faster.
Who says that?
As already stated, I don't consider these as either light-weight nor
faster. Here is a benchmark.
Below are 2
At 10:03 PM +0100 11/17/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
[ this came up WRT calling conventions ]
I assume he's doing bsr/ret to get into and out of the sub, which
is going to be significantly faster.
Who says that?
As already stated, I don't consider these as either light-weight
At 5:08 PM -0500 11/17/04, Dan Sugalski wrote:
Chopping out the multiplication (since that's a not-insignificant
amount of the runtime for the bsr/ret version) gives:
PIR:
real0m3.016s
user0m2.990s
sys 0m0.030s
bsr/ret
real0m0.344s
user0m0.340s
sys 0m0.010s
and with -Oc,
On Wed, Nov 17, 2004 at 10:03:14PM +0100, Leopold Toetsch wrote:
As already stated, I don't consider these as either light-weight nor
faster. Here is a benchmark.
Below are 2 version of a recursive factorial program. fact(100) is
calculated 1000 times:
PIR 1.1 s
bsr/ret
On Wed, Nov 17, 2004 at 10:03:14PM +0100, Leopold Toetsch wrote:
Dan Sugalski wrote:
As already stated, I don't consider these as either light-weight nor
faster. Here is a benchmark.
Below are 2 version of a recursive factorial program. fact(100) is
calculated 1000 times:
PIR
On Wed, Nov 17, 2004 at 02:47:09PM -0700, Patrick R. Michaud wrote:
BTW, it may be very possible for me to write the p6ge generator so
that it can be switched between the PIR and bsr/ret calling conventions,
so we don't need to resolve this entirely now. And we could then benchmark
the two
Apparently it's not happy with things of the form
foo = bar * .95
where the RHS of the binary operation is a floating point constant
with no integer portion. Changing it to 0.95 works, so I assume the
grammar just needs a tweak.
--
Dan
Dan Sugalski [EMAIL PROTECTED] wrote:
Apparently it's not happy with things of the form
foo = bar * .95
where the RHS of the binary operation is a floating point constant
with no integer portion. Changing it to 0.95 works, so I assume the
grammar just needs a tweak.
Yep. The lexer
the
grammar just needs a tweak.
Yep. The lexer (imcc.l) is missing this case.
Patches welcome,
It'd help if I could actually rebuild this so it could be tested...
This is the patch. It should work but the version of flex I have installed
doesn't play nice with the rest of the source, so I can't
Dan Sugalski [EMAIL PROTECTED] wrote:
It'd help if I could actually rebuild this so it could be tested...
Works. Applied. Tests ok. Thanks,
leo
[EMAIL PROTECTED] (Jeff) writes:
The subject pretty much says it all. The format pretty much corresponds
to the upcoming Exegesis. Major changes were to the modifiers, and a few
syntax changes in the depths.
I've started rewriting my Shishi P6 RE module since it was becoming
way too
The subject pretty much says it all. The format pretty much corresponds
to the upcoming Exegesis. Major changes were to the modifiers, and a few
syntax changes in the depths.
Sean, feel free to take what you can use (if anything) from this and
delete the rest.
--
Jeff [EMAIL PROTECTED]
On Tue, 16 Jul 2002, John Porter wrote:
In his P6 Summary for 2002-07-14, in section
Perl 6 grammar, take 5, Piers says:
someone pointed out that [the grammar] had a problem
with code like
{ some_function_returning_a_hash() }
Should it give a closure? Or a hash
- more compiler tests.
- more parser tests (John Kingsley).
- more docs.
- a bit more speed in the grammar by using regexes rather than a rule
to hype operators
- sub parameter lists will affect parsing (e.g. sub foo($x) will be
a unary operator).
Fixes:
- || and on lists return lists instead
It's time for my weekly post to this old thread. The grammar has
grown enough to deserve more than one file, and is starting to change
in new directions. For example, it's now Turing-complete, if you have
a Parrot engine and a bit of spare time. Call it a primitive demo
version of some of Perl
On Fri, 2002-07-12 at 02:33, Sean O'Rourke wrote:
What's currently supported:
- if/elsif/else (even unless and the feared elsunless;)
When we talked about this last, I had been concerned about loops and
conditionals, but others had scoping concerns. Ok, perhaps there's no
way we can roll in
At 11:33 PM -0700 7/11/02, Sean O'Rourke wrote:
It's time for my weekly post to this old thread. The grammar has
grown enough to deserve more than one file, and is starting to change
in new directions. For example, it's now Turing-complete, if you have
a Parrot engine and a bit of spare time
I keep expecting Damian or Larry or someone to step in with The True
Grammar and make this obsolete -- does such a thing exist?
Changes in this version:
- A bit more speed (though nowhere near enough). It comes from a
combination of improving rule ordering, inlining some rules, moving
most
In a message dated Sat, 6 Jul 2002, Sean O'Rourke writes:
- Implicit currying variables ($^a etc) are in. I thought I had read
somewhere they were gone in favor of closure args, but people seem
to be using them, and they're not hard to put in.
My understanding is that they still exist as
On Sat, 6 Jul 2002, Trey Harris wrote:
: In a message dated Sat, 6 Jul 2002, Sean O'Rourke writes:
: - Implicit currying variables ($^a etc) are in. I thought I had read
:somewhere they were gone in favor of closure args, but people seem
:to be using them, and they're not hard to put
, write to STDOUT
--dumperuse Data::Dumper to generate output
--rule NAME start with rule NAME (default = 'stmts')
--cache use precompiled grammar
In interactive mode, output is terminated by a blank line.
END
$::RD_TRACE = $o{trace};
$::rule = $o
For some reason I feel really, really bad saying this --
in fact, I'm warming up the flog right now -- but, um,
maybe Damian should write it?
__
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
. The attempt has certainly given
me a much better understanding of Perl (both 5 and 6) than I had before as
a mere user. If there's anyone else out there with the time for and
interest in working on a Parse::RecDescent grammar, feel free to speak up.
but I wrote a list of variables I'll try
. The attempt has certainly given
me a much better understanding of Perl (both 5 and 6) than I had before as
a mere user. If there's anyone else out there with the time for and
interest in working on a Parse::RecDescent grammar, feel free to speak up.
I don't want to do it in Parse::RecDescent
So, it's been a week or so and, while I'm mostly offline until
wednesday, I'll ask the question...
How's the work on the perl 6 grammar going? We any further along than
we were before YAPC?
--
Dan
--it's like
understanding of Perl (both 5 and 6) than I had before as
a mere user. If there's anyone else out there with the time for and
interest in working on a Parse::RecDescent grammar, feel free to speak up.
but I wrote a list of variables I'll try to parse using any
grammars which go by. Are all
the characteristics of Perl6's grammar.
I'd suggest first reading Apocalypse 5, because the features presented
there are supposed to play an important part in implementing perl6's
grammar itself. Or at least in allowing people to extend it.
--
Bart.
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, 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 style
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 start
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
Eek, I really don't talk that way, hurriedly typed messages come off
looking like I'm in 5th grade with all the spelling errors..
-Melvin Smith
IBM :: Atlanta Innovation Center
[EMAIL PROTECTED] :: 770-835-6984
78 matches
Mail list logo
