Re: access to parser stack in SMIE

[Stefan Monnier]

> 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.

>> But I wonder now: can a "begin" that comes right after a "function
>> ... end;" be a begin-open?  

> package Package_1 is 

>     function Function_1 return Integer
>     is begin
>        return 1;
>     end;

> begin

> That isn't "begin-open". But how can you be sure that's the case you
> have? You can't just stop a the "end"; consider:

No, but if you have

   package Package_1 is 
       function Function_1 return Integer
       is begin return 1; end;
       function Function_2 return Integer
       is begin return 2; end;
   begin

you can stop when you see the first "function".  I'd expect that within
a package there are usually several functions, so parsing backward
a single function doesn't sound bad compared to parsing forward the
whole file.

> work. 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.
              
> Too much ad-hoc code.

You might be right.

>           (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...

> I guess you could provide a function that scans the stack, skipping ";",
> and returning the next token. That would work in this particular case,
> but I'm not sure about the other cases I need.

I have to think it over some more,


        Stefan