[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [FR-devel] RE: bRuby? (Yet another Ruby parser)
From: |
Hal E. Fulton |
Subject: |
Re: [FR-devel] RE: bRuby? (Yet another Ruby parser) |
Date: |
Thu, 7 Nov 2002 20:13:00 -0600 |
----- Original Message -----
From: "Bob Calco" <address@hidden>
To: <address@hidden>; <address@hidden>
Sent: Thursday, November 07, 2002 3:58 PM
Subject: RE: [FR-devel] RE: bRuby? (Yet another Ruby parser)
> Phil:
>
> My parser will take the idea of separation from the runtime to its logical
> conclusion and provide a very flexible API for attaching the wires and
plugs
> to whatever backend might need to walk the AST, for whatever purpose.
While we're on the topic: I'm ignorant of parsers
(I've written a couple of compilers and such) but
I do have an idea to pass along.
Take it for what it's worth.
Since the editor will make heavy use of the parser
I think the parser should expose state as much as
appropriate (for this kind of specialized app, not
for the typical app perhaps).
What I mean is, suppose we have this code fragment:
def alpha(...)
...
end
def beta(...)
...
end
def gamma(...)
...
end
And suppose we are editing the beta method. It would
be nice if the editor somehow knew to keep checkpoints
of some kind, so that re-parsing during editing need
only happen with a certain syntactic region.
Might also provide a way for the editor to tell the
parser which parts of the text are "dirty" and need
to be re-parsed.
Obviously we want to 1) parse on the fly and 2) avoid
a manual triggering such as we have now and 3) avoid
reparsing from the ground up every time.
I've no idea how to accomplish this, but it would be
nice. :)
Hal