Re: [cl-ppcre-devel] Roles of scanner vs. parser vs. lexer?
[You forgot to Cc the mailing list.] On Wed, 3 Aug 2005 15:49:58 -0700, Derek Peschel <dpeschel@eskimo.com> wrote:
CL-PPCRE makes a start, with a grammar and a set of token types that the lexer produces. The problem, as you know, is how to make sure the specification is complete while stating it in a way that's not tied to a particular implementation. All the context-sensitive tricks (extended mode, backreference vs. octal constants, \Q and \E) make the spec harder to check too.
Definitely. I'm afraid I won't be able to help very much, though. CL-PPCRE's parser/lexer is very much an ad hoc implementation and it's the first parser I ever wrote.
Climacs's syntax highlighters work with parse trees, so CL-PPCRE's use of them seemed to make it a good match for Climacs. I think Climacs needs to reconstruct the original text from the parse tree, and it parses the text incrementally, and a good syntax module will flag errors yet allow further changes to the text. So I don't know if the Climacs parse tree could be ready to pass to CL-PPCRE. But that would be ideal.
Without knowing anything about Climacs' internals: How about using CL-PPCRE::PARSE-STRING and feeding the result to Climacs?
Are dangling \Es legal in Perl too?
Yep. edi@vmware:~$ perl -le '$a = "\Q*\E\E"; print $a' \* Cheers, Edi.
On Thu, Aug 04, 2005 at 01:32:37AM +0200, Edi Weitz wrote:
[You forgot to Cc the mailing list.]
Oops. Every list works differently. If I reply to you and Cc the list, is the server smart enough not to send you a second copy? For myself, I have the "don't send me copies of my posts" option on (Mutt already saves a copy) so that would be a logical extension as long as everyone uses it and everyone remembers to Cc the list.
Without knowing anything about Climacs' internals: How about using CL-PPCRE::PARSE-STRING and feeding the result to Climacs?
That might be OK. But the incremental parser algorithm keeps a lot more state than just the parse tree, I think. You don't have to worry about the algorithm, but you do have to use Climacs's classes to describe your language. You need to preserve _all_ original text, since I believe Climacs uses the parse tree to display the buffer, and I'd say you need to recover from errors by continuing to parse (maybe in some restricted way) past them. Considering these requirements it seems sensible to rewrite the parser using Climacs's framework. -- Derek
On Wed, 3 Aug 2005 23:34:52 -0700, Derek Peschel <dpeschel@eskimo.com> wrote:
Oops. Every list works differently. If I reply to you and Cc the list, is the server smart enough not to send you a second copy?
No, but my procmailrc takes care of that.
Considering these requirements it seems sensible to rewrite the parser using Climacs's framework.
OK, good luck. Cheers, Edi.
participants (2)
-
Derek Peschel -
Edi Weitz