From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: Re: access to parser stack in SMIE Date: Sun, 07 Oct 2012 21:28:26 -0400 Message-ID: <857gr1da6d.fsf@member.fsf.org> References: <85pq4wgrho.fsf@member.fsf.org> <85lifjfn10.fsf@member.fsf.org> <85wqz1dg7k.fsf@member.fsf.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1349660017 11901 80.91.229.3 (8 Oct 2012 01:33:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 8 Oct 2012 01:33:37 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 08 03:33:44 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TL2E3-0005iP-00 for ged-emacs-devel@m.gmane.org; Mon, 08 Oct 2012 03:33:43 +0200 Original-Received: from localhost ([::1]:58426 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TL2Dw-0004QC-7K for ged-emacs-devel@m.gmane.org; Sun, 07 Oct 2012 21:33:36 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:41955) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TL2Ds-0004Q6-HR for emacs-devel@gnu.org; Sun, 07 Oct 2012 21:33:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TL2Dr-0005Rv-F7 for emacs-devel@gnu.org; Sun, 07 Oct 2012 21:33:32 -0400 Original-Received: from qmta08.westchester.pa.mail.comcast.net ([76.96.62.80]:40904) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TL2Dr-0005Rr-Bs for emacs-devel@gnu.org; Sun, 07 Oct 2012 21:33:31 -0400 Original-Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta08.westchester.pa.mail.comcast.net with comcast id 8RRe1k0011wpRvQ58RZbA1; Mon, 08 Oct 2012 01:33:35 +0000 Original-Received: from TAKVER ([69.140.67.196]) by omta18.westchester.pa.mail.comcast.net with comcast id 8Rlr1k0034E4Fsd3eRlrHl; Mon, 08 Oct 2012 01:45:51 +0000 In-Reply-To: (Stefan Monnier's message of "Sun, 07 Oct 2012 21:00:11 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (windows-nt) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 76.96.62.80 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:154213 Archived-At: Stefan Monnier writes: >> Yes. Which is why the cache is critical. And improving the cache by >> storing the stack at each keyword would be even better. > > That can lead to a very large cache, which can then become slow to > manage. In syntax-ppss we keep the intermediate state of the parse > every ~20KB. So that if we have to re-parse at most ~20KB's worth > of text. That makes sense. >> But it's messier and less general than the forward parse >> mechanism, and the other tokens that need forward parse would need their >> own variations. > > I get the impression that a > > (let ((begin-flavor nil)) > (while (let ((s (smie-backward-sexp 'halfsexp))) > (null (setq begin-flavor (ada--begin-flavor s)))))) > > wouldn't be that hard to write and that ada--begin-flavor would look > similar to your current function that looks at the stack items. > But of course, here, details matter, so we can't know without actually > trying it out. Yes. I should look at this again; it might be better than what I have now. >> (setq stack-token (nth 0 (rassoc (pop stack) ada-indent-grammar))) > > Hmm... indeed, by relying on the identity of the cons cells in the > stack, you can recover the actual token, even if 2 tokens have the same > left&right precedence. > It should be the case in all real-life situations, but nothing > guarantees that it's the case. > Hmm... Ah, I never even considered that it might not be unique. That makes this technique less satisfactory; to be safe, we'd have to add the actual token to the stack. I did wonder why the stack didn't have the actual token; I guess you didn't need it for anything yet. -- -- Stephe