Front page | perl.perl6.internals.api.parser |
Postings from December 2000
Re: Now, to try again...
Thread Previous
|
Thread Next
From:
David Grove
Date:
December 18, 2000 10:51
Subject:
Re: Now, to try again...
Message ID:
200012181935.eBIJZWm05582@camel.petes-place.com
Nicholas Clark <nick@ccl4.org> wrote:
> On Mon, Dec 18, 2000 at 11:30:09AM +0000, David Grove wrote:
> >
> > Bart Lateur <bart.lateur@skynet.be> wrote:
>
> > > 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
>
> When I made the suggestion to give the perl parser enough API to let
> an editor use it for syntax highlighting, I was thinking of an editor
> written in C with embedded perl. Such as emacs or vi.
>
> I didn't say that anyone should actually do it :-)
Too late. ;-)
> [or that it wouldn't be usably fast on anything expensive enough to
come
> with less than 1Gb RAM as standard]
> Just that it would be nice if the parser API were flexible enough to
make
> it possible (if not easy) for someone to do it.
> As it seemed to be a bit of parser API we'd not yet considered.
> And this is the parser-api list, so it seemed very on topic.
>
> I think I'm not wrong in saying that making the parser state totally
> encapsulated makes the parser restartable and goes a long way to making
> it re-entrant.
Actually, I'm fascinated with the possibilities if it's feasible. Any
objections to a private convo to come up with something feasible? I've hit
these issues pretty hard in the past. Maybe we can come up with something
completely feasible.
p
Thread Previous
|
Thread Next