technology?
Thanks,
Santhosh
PS: I am assuming we are not moving to Antlr.
-Original Message-
From: Alan Gates [mailto:ga...@yahoo-inc.com]
Sent: Tuesday, February 24, 2009 10:17 AM
To: pig-dev@hadoop.apache.org; pi.so...@gmail.com
Subject: Re: switching to different parser in Pig
: Tuesday, August 25, 2009 12:52 PM
To: pig-dev@hadoop.apache.org; Dmitriy Ryaboy
Cc: pi.so...@gmail.com
Subject: Re: switching to different parser in Pig
Jflex is covered by GPL, but code generated by it is not. Only the code that
is generated by Jflex goes into pig.jar.
We can't checkin Jflex.jar
(1) Lack of good documentation which makes it hard to and time consuming
to learn javacc and make changes to Pig grammar
== ANTLR is very very well documented.
http://www.pragprog.com/titles/tpantlr/the-definitive-antlr-reference
http://media.pragprog.com/titles/tpantlr/toc.pdf
Sorry, after I sent that email yesterday I realized I was not very
clear. I did not mean to imply that antlr didn't have good
documentation or good error handling. What I wanted to say was we
want all three of those things, and it didn't appear that antlr
provided all three, since it
Yes.
And one thing I should have mentioned was Chris W's thoughts along the lines
that it would be very nice to expose the logical plan to something like
Cascading so that a global restructuring could be done across more than just
Pig programs. It works the other way as well, with it becoming
Sounds good but how about exposing the logical plan layer instead? Wouldn't
that yield the same effect? From python for example you still can construct
a logical plan and give to Pig to execute.
On Wed, Feb 18, 2009 at 10:07 AM, Ted Dunning ted.dunn...@gmail.com wrote:
2009/2/17 Alan Gates
Probably nearly the same effect as you suggest. Are the concepts at the
logical plan layer similar to those expressed in pig latin? Or has a
significant transformation occurred by then?
On Fri, Feb 20, 2009 at 1:59 AM, pi song pi.so...@gmail.com wrote:
Sounds good but how about exposing the
Pig Developers,
Pig currently uses javacc for parsing pig commands. We have found
several shortcomings with using javacc. In particular,
(1) Lack of good documentation which makes it hard to and time consuming
to learn javacc and make changes to Pig grammar
(2) No easy way to customize error
This sounds like a great idea !
Would be great if other means of generating ast's for pig was possible.
Regards,
Mridul
Ted Dunning wrote:
In general, it would be really, really nice if it were easy to build
abstract Pig syntax trees outside of the normal parser.
For instance, I find the
