From: Stefan Monnier <monnier@IRO.UMontreal.CA>
To: Stephen Leake <stephen_leake@member.fsf.org>
Cc: emacs-devel <emacs-devel@gnu.org>
Subject: Re: access to parser stack in SMIE
Date: Sun, 07 Oct 2012 15:04:56 -0400 [thread overview]
Message-ID: <jwv8vbi2k38.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <85lifjfn10.fsf@member.fsf.org> (Stephen Leake's message of "Sat, 06 Oct 2012 14:55:39 -0400")
>> Actually, in some cases, it can be made to work: to disambiguate "begin"
>> setup a loop that calls smie-backward-sexp repeatedly (starting from the
>> position just before the "begin", of course) checking after each call
>> whether the result lets us decide which of the two begins we're
>> dealing with.
> In the Ada use case I presented (package ... begin), that ends up going
> all the way back to package at the beginning of the buffer, encountering
> more "begin" tokens on the way; it's much more efficient to start there
> in the first place.
In your example, we might indeed end up scanning the buffer 3 times
(once for the normal scan, once to disambiguate package's `begin', and
one more time (in various chunks) to disambiguate the `begin's of the
nested functions).
But I wonder now: can a "begin" that comes right after a "function
... end;" be a begin-open? I don't think so (but my Ada is rusty and
outdated). So you might really not need to scan that far back.
>> Right, if we want to make the stack visible, then we also need to
>> implement the cache.
> Ok. Although different languages may want to cache different things, so
> I'm not sure that would really be common code.
We'd make smie.el cache the whole stack state at various buffer
positions (just like we do for the syntax-ppss cache).
>> - risk of the cache going out of sync.
> Yes. I've already got an interactive `ada-indent-invalidate-cache' to
> handle that, but the user will have to be aware. So far, the cache has
> not gotten out of sync, but I haven't used this to write real
> code yet.
I don't think there is that much to worry about in general.
> Switching to another parsing technology just for the forward full-parse
> means supporting a second grammar; that's a lot of work. It might be
> simpler to switch to only forward full-parse (which I think is what you
> are suggesting).
Yes, if you end up doing a full forward parse in most cases anyway,
there's little point doing extra work to support backward parsing.
> If I switch to only using forward full-parse, I'd have to do things
> differently in the indentation rules as well. The key information they
> need need is the location of the statement start for every indentation
> point. So the forward parse could store the relevant statement start
> (and maybe other stuff) with every token.
Indeed.
> Hmm. The actual change to smie I'm asking for is very small (if we
> leave out the cache); perhaps you could put that in, with a large "use
> at your own risk" comment?
Indeed, just exposing the stack is not that bad, and lets you solve your
problem. But it's kind of ugly. Maybe I could instead provide
a function that lets you query the particular part of the stack that
you're interested in (that would make it easier to adapt to a new
format of the stack, for example).
Could you describe which part of the stack you need to know?
Stefan
next prev parent reply other threads:[~2012-10-07 19:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-06 4:21 access to parser stack in SMIE Stephen Leake
2012-10-06 12:37 ` Stefan Monnier
2012-10-06 18:55 ` Stephen Leake
2012-10-07 19:04 ` Stefan Monnier [this message]
2012-10-07 23:18 ` Stephen Leake
2012-10-08 1:00 ` Stefan Monnier
2012-10-08 1:28 ` Stephen Leake
2012-10-08 22:58 ` Stephen Leake
2012-10-09 2:26 ` Stefan Monnier
2012-10-09 3:29 ` Stephen Leake
2012-10-09 4:20 ` Stefan Monnier
2012-10-09 11:23 ` Stephen Leake
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwv8vbi2k38.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=emacs-devel@gnu.org \
--cc=stephen_leake@member.fsf.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.