Re: Now, to try again...
[email protected] ("David Grove") Mon, 18 Dec 2000 11:30:09
| Newsgroups | perl.perl6.internals.api.parser |
|---|---|
| Message-ID | <[email protected]> |
Bart Lateur <[email protected]> wrote: > On Sun, 17 Dec 2000 14:11:50 -0700 (MST), Nathan Torkington wrote: > > >I think the problems with this that were raised in the past are: > > * parsing partial source > > * does this mean that the parser has to reparse the whole sourcefile > > every time you type a character? > > Hold it. I don't think that is very practical, and for more than one > reason. [snip] > But, the gist of this post is: we don't want to loose the usefulness of > the syntax highlighter, as soon as there is one syntax error in the > script, because this will be the normal situation while editing source. > Parsers are generally very bad at parsing erroneous code. You're forgetting something. Any such editor would have to be written either in Perl, or in C with builtin Perl, in order to gain access to this type of parser feedback. That or we'd have to communicate with perl somehow, or the parser somehow. With that there's a huge problem: speed. A full-fledged editor in Perl is very, very slow. That's how CodeMagic started out. Perl had to talk to Tk (or whatever) which slows us down in the first place. Add perl interpreter hooks into the mix, you get something unusable on anything less than a TBird 1G. Finding keywords is one thing, that's easy and fairly quick. However, finding structures (matching quotes, /'s, parens, braces, brackets, and understanding perl grammar is quite a different story. The several layers of IPC got in the way to the extent that I had to externalize it completely. I don't think this is a parser issue at all, unless you want to parse a file during composition. That provides an interesting new set of possibilities, but you still have speed issues nonetheless. p