Re: [pro] Is cl-yacc going to cut it?

2011-02-14 Thread Daniel Herring
On Mon, 14 Feb 2011, William Halliburton wrote: I know I'm late to the parade but if you need to write grammars that can be easily augmented by other people without them needing to know much, if any, lisp I can recommend the ebnf parser written by Daniel Herring.  Its onion of macros expands in

Re: [pro] Is cl-yacc going to cut it?

2011-02-14 Thread William Halliburton
I know I'm late to the parade but if you need to write grammars that can be easily augmented by other people without them needing to know much, if any, lisp I can recommend the ebnf parser written by Daniel Herring. Its onion of macros expands into pretty understandable code also. http://git.andr

Re: [pro] Is cl-yacc going to cut it?

2011-02-14 Thread Scott L. Burson
On Mon, Feb 14, 2011 at 2:43 AM, Samium Gromoff <_deepf...@feelingofgreen.ru> wrote: > I'm surprised that nobody has mentioned OMeta/ometa2 as of yet. > > It has this boolean functionality you speak of: I wasn't familiar with it. Based on a quick glance I don't think it can handle boolean grammar

Re: [pro] Is cl-yacc going to cut it?

2011-02-14 Thread Samium Gromoff
On Sat, 5 Feb 2011 13:29:39 -0800, "Scott L. Burson" wrote: > Boolean grammars solve both these problems. Let's look at how they work. > > The key insight is that we consider nonterminal definitions to be > operations on predicates over strings. The definition > > A ::= B | C > > is fundam

Re: [pro] Is cl-yacc going to cut it?

2011-02-06 Thread Matthew D. Swank
On 02/04/2011 02:39 PM, Scott L. Burson wrote: > It is an abuse in the sense that it makes it harder to say formally > exactly what language you're parsing, but hey, you do what you have to > do in this business :-) > I ended up writing a lexer start condtion generator that derives its state machin

Re: [pro] Is cl-yacc going to cut it?

2011-02-05 Thread Scott L. Burson
On Fri, Feb 4, 2011 at 8:06 AM, Pascal J. Bourguignon wrote: > > I would also note that given that context free languages include regular > languages, there's also little theorical point in distinguishing a lexer > from a parser: you can describe the tokens using normal grammar rules. > > space-or

Re: [pro] Is cl-yacc going to cut it?

2011-02-04 Thread Pascal J. Bourguignon
Paul Tarvydas writes: >> symbol parse, but is there another general parsing technique, available >> as a lisp library of course, that either works at a lower level than >> yacc usually does or allows the lexer to access more context about the >> parse? > > The relatively new PEG packrat parser t

Re: [pro] Is cl-yacc going to cut it?

2011-02-04 Thread Matthew D. Swank
In fact I should have consolidated my replies, but by the time I realized I was probably spamming the list, I was too far in. I used to get impression that writing parsers in lisp was like moon-shining: lots of people had rough and ready parsers out in the back woods, but didn't really like talkin

Re: [pro] Is cl-yacc going to cut it?

2011-02-04 Thread Matthew D. Swank
I would be very interested to see that if it ever become something you'd be comfortable releasing. On 02/04/2011 02:39 PM, Scott L. Burson wrote: > My own pet parser generator project is a CL reimplementation of Adam > Megacz' Scannerless Boolean Parser: > http://research.cs.berkeley.edu/project/sb

Re: [pro] Is cl-yacc going to cut it?

2011-02-04 Thread Matthew D. Swank
Meta does seem like a parser for people allergic to parsing. Of course it has a great lisp pedigree as well. I am biased by early exposure to Ken Thompson's work on regular expressions and LALR parsers. Matt On 02/04/2011 09:31 AM, Thomas M. Hermann wrote: > I am absolutely biased towards meta-

Re: [pro] Is cl-yacc going to cut it?

2011-02-04 Thread Matthew D. Swank
I had heard about cl-peg, but not Esrap. Most of the time I can get away with the space requirements need by both parser combinators and and pack-rat parsers, but there are some large documents where that isn't practical. One thing I would like to eventually see is a mature library that can take

Re: [pro] Is cl-yacc going to cut it?

2011-02-04 Thread Matthew D. Swank
Yeah, that is basically what I'm doing: driving start conditions from the parser. One hint that there was unnecessary code duplication going on was when the state in some of my older lexers started looking like shift entries in the parser's action table. Matt On 02/04/2011 01:21 AM, Raymond Wike

Re: [pro] Is cl-yacc going to cut it?

2011-02-04 Thread Daniel Weinreb
So the next time anyone says that there aren't any libraries for Common Lisp, we can reply that there are so many good parser libraries that one must compare notes to figure out which is best for which situation. So there, ye of little faith! :) -- Dan Scott L. Burson wrote: On Thu, Feb 3, 20

Re: [pro] Is cl-yacc going to cut it?

2011-02-04 Thread Scott L. Burson
On Thu, Feb 3, 2011 at 10:33 PM, Matthew D. Swank wrote: > It seems (from my admittedly limited search) that this is not a common > modification of yacc.  Before I start bugging the maintainer about my > changes, I want to know: am I abusing yacc? I've had to do that kind of thing for parsing lan

Re: [pro] Is cl-yacc going to cut it?

2011-02-04 Thread Thomas M. Hermann
I am absolutely biased towards meta-sexp: "A META parser generator using LL(1) grammars with s-expressions." https://github.com/vy/meta-sexp It seems dirt simple to use, at least to me and the performance has been acceptable. Regards, ~ Tom -

Re: [pro] Is cl-yacc going to cut it?

2011-02-04 Thread Nikodemus Siivola
On 4 February 2011 16:39, Paul Tarvydas wrote: > The relatively new PEG packrat parser technologies make it possible > to use just one universal description for, both, scanning and > parsing.  I see that cl-peg exists, but I haven't tried it out. Esrap is another packrat parser for CL: https

Re: [pro] Is cl-yacc going to cut it?

2011-02-04 Thread Paul Tarvydas
> symbol parse, but is there another general parsing technique, available > as a lisp library of course, that either works at a lower level than > yacc usually does or allows the lexer to access more context about the > parse? The relatively new PEG packrat parser technologies make it possible to

Re: [pro] Is cl-yacc going to cut it?

2011-02-03 Thread Cyrus Harmon
I've been very pleased with cl-parser-combinators. Not sure what you're trying to parse, but it's pretty flexible and powerful. I've used it for parsing a printed representation of molecules, SMILES strings, and have found it to be a pleasure to work with. Cyrus On Feb 3, 2011, at 10:33 PM, Ma

Re: [pro] Is cl-yacc going to cut it?

2011-02-03 Thread Matthew D. Swank
It does look nice, and parser combinators are very cool, but I scrape a lot of semi structured documents. Sometimes it's hard to operate with all of it in memory, which is a current requirement of cl-parser-combinators. Thank you though, Matt On 02/04/2011 01:14 AM, Cyrus Harmon wrote: > I've be

Re: [pro] Is cl-yacc going to cut it?

2011-02-03 Thread Raymond Wiker
I've used cl-yacc exactly once, and chose to implement "start conditions" in my lexer - I use a closed-over variable to restrict the set of patterns that I want to match in the lexer. I set and test the start-condition in the lexer only, but it would certainly to be possible to modify the start con

[pro] Is cl-yacc going to cut it?

2011-02-03 Thread Matthew D. Swank
I suppose this is only marginally related to common lisp, but everything I'm talking about is written in common lisp. I use cl-yacc for a lot of parsing, but one thing that has always seemed harder than it needs to be is writing lexers to feed it. One thing that I've found helpful is the creation