JParsec is a recursive descent parser combinator framework. Unlike traditional parser generators (javacc, antlr, etc), no additional grammar file is required. Declarative Java API is provided to create grammar programmatically and dynamically.
Because of the dynamic nature of JParsec, operator-precedence and context-sensitive grammar can be constructed. Grammars can then be reused and parameterized just as any other normal Java objects.
JParsec is a port of the Haskell Parsec framework.
-
JParsec released (10 messages)
- Posted by: Ben Yu
- Posted on: March 22 2006 21:15 EST
Threaded Messages (10)
- What kind of XML works best for Parsec? by Frank Cohen on March 27 2006 16:04 EST
- What kind of XML works best for Parsec? by Ben Yu on March 28 2006 11:43 EST
- License Clarification by Niall Pemberton on March 27 2006 21:22 EST
- License Clarification by Mikhail Kotelnikov on March 28 2006 03:57 EST
- License Clarification by Niall Pemberton on March 28 2006 07:15 EST
- License Clarification by Mikhail Kotelnikov on March 28 2006 03:57 EST
- JParsec released by Geert Bevin on March 28 2006 02:39 EST
- Contact information by Mikhail Kotelnikov on March 29 2006 03:38 EST
- Contact information by Ben Yu on March 29 2006 10:55 EST
- Contact information by Ben Yu on March 29 2006 18:47 EST
- Contact information by Mikhail Kotelnikov on March 30 2006 01:29 EST
-
What kind of XML works best for Parsec?[ Go to top ]
- Posted by: Frank Cohen
- Posted on: March 27 2006 16:04 EST
- in response to Ben Yu
One of the patterns that I put forward at the TSS Symposium last week is to use the XML parser that Is appropriate to your data. Applying the wrong parser is normally an opportunity for poor performance. I tend to see three types of XML data in an SOA environment and three patterns for XML parsing apply:
1) The TV Dinner Pattern
Good for large XML documents with complex schemas
Bad for shallow schemas and small payload sizes
Example technology: JAXB, XMLBeans
2) The Sushi Boats Pattern
Good for large XML documents with simple schemas
Bad for complex schemas
Example technology: StAX
3) The Buffet Pattern
Good for small XML documents with simple schemas
Bad for complex schemas and large payload sizes
Example technology: Xerces, JAX-RPC
I can't tell from the Parsec documentation which type of XML data would be best for high performance?
-Frank Cohen
http://www.xquerynow.com -
What kind of XML works best for Parsec?[ Go to top ]
- Posted by: Ben Yu
- Posted on: March 28 2006 11:43 EST
- in response to Frank Cohen
Frank,
I see no reason why one would want to use jparsec for a xml doc. JParsec is a tool to _create_ parser, while for xml, various mature parser products are already created for us and ready to use.
jparsec is for other more ad-hoc style parsing where one wants to construct a parser quick and easy, or when dynamic grammar is required.
Rgds,
Ben -
License Clarification[ Go to top ]
- Posted by: Niall Pemberton
- Posted on: March 27 2006 21:22 EST
- in response to Ben Yu
Copyright (c) 2005, Zephyr Business Solutions Corp.
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
Redistributions of source code must retain the above copyright notice, this
list of conditions and the following disclaimer.
Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
Neither the name of the Zephyr Business Solutions Corp nor the names of its
contributors may be used to endorse or promote products derived from this
software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
The license looks pretty liberal, but it would provide greater clarity if it used one of the reconginsed Open Source licenses (but hopefully not GPL/LGPL). Does anyone know a link/email address for contacting Zephyr? -
License Clarification[ Go to top ]
- Posted by: Mikhail Kotelnikov
- Posted on: March 28 2006 03:57 EST
- in response to Niall Pemberton
This is BSD license, so it is recognized by OSS. Please check this link: http://www.opensource.org/licenses/bsd-license.php -
License Clarification[ Go to top ]
- Posted by: Niall Pemberton
- Posted on: March 28 2006 07:15 EST
- in response to Mikhail Kotelnikov
This is BSD license, so it is recognized by OSS. Please check this link: http://www.opensource.org/licenses/bsd-license.php
Thanks -
JParsec released[ Go to top ]
- Posted by: Geert Bevin
- Posted on: March 28 2006 02:39 EST
- in response to Ben Yu
The declarative Java API is very alluring, I'm definitely keeping this one in mind for the next parsing tasks we need to do. -
Contact information[ Go to top ]
- Posted by: Mikhail Kotelnikov
- Posted on: March 29 2006 03:38 EST
- in response to Ben Yu
Thanks a lot for the pointer to jParsec! It is really the library that I was looking for for a long time!
But I have some problems with jParsec and I can't find any contact information on the site nor in source/binary distributions. So I have to put my questions right here. I hope that they are not completely out of topic...
I downloaded jParsec package, but, unfortunately, I can't run test cases. I have a strange runtime exception cased by the class "jfun.util.IntArray" from jfunutil.jar library:
java.lang.UnsupportedClassVersionError: jfun/util/IntArray (Unsupported major.minor version 49.0)
...
I use Eclipse 3.2 with Sun's JDK 1.4.2_10. I think that it is a problem of different compiler/JRE versions.
By the way - why there is no sources for utility classes for this library (jfunutil.jar)? I saw only 2 really used classes (jfun.util.IntArray and jfun.util.Misc) and I think that it make sense to put them directly in jparser source distribution.
Thanks in advance! -
Contact information[ Go to top ]
- Posted by: Ben Yu
- Posted on: March 29 2006 10:55 EST
- in response to Mikhail Kotelnikov
Hi, Mikhail
Thanks for bringing that up.
The contact info is actually _deeply_ buried inside the tutorial (the bottom). I'll add contact info on the home page. Anyway, this is my email: ajoo dot email at gmail dot com
I also added mail list info to the home page.
As for the jfunutil. That's a very good point. I should also include the source code in there too. I'll work on that tonight.
The java version problem is probably because of jdk version mismatch. Once you have the source code, you can compile without such problem.
Ben -
Contact information[ Go to top ]
- Posted by: Ben Yu
- Posted on: March 29 2006 18:47 EST
- in response to Mikhail Kotelnikov
jfunutil source code included in the release. Please check it out.
Just follow the download link on the home page. -
Contact information[ Go to top ]
- Posted by: Mikhail Kotelnikov
- Posted on: March 30 2006 01:29 EST
- in response to Ben Yu
Thanks a lot!