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
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
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
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-
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
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
On 4 February 2011 23:00, Daniel Weinreb wrote:
> Has anybody written a domain-specific-language
> set of macros (or functions) to provide "awk"
> functionality from Common Lisp, with roughly
> the kind of brevity that awk users like?
I haven't tried it or looked at it, but there is CLAWK:
htt
Has anybody written a domain-specific-language
set of macros (or functions) to provide "awk"
functionality from Common Lisp, with roughly
the kind of brevity that awk users like?
-- Dan
___
pro mailing list
pro@common-lisp.net
http://common-lisp.net/cg
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
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
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
-
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
> 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
13 matches
Mail list logo
