Re: Is it always possible to make a non-reentrant parser reentrant?

[Hans Åberg]

> On 12 Feb 2019, at 20:27, Peng Yu <address@hidden> wrote:
> 
>> We should probably offer an example of a pull parser in examples/c.
>> Have a look at the documentation to have an idea of what I mean.
> 
> OK. I will take a look at it.
> 
> Bash uses one parser to deal with both interactive run and
> non-interactive run and uses a global variable to test whether the run
> is interactive in many places in the code. This makes the
> non-interactive run inefficient. For this reason, I'd like to make two
> parsers --- one to deal with bash code interactively and another one
> to compile it (either JIT or compile it into binary) and run. Do you
> think this is a good strategy?
> 
> How to deal with the code that is in common between the two? What is
> the standard practice to handle both interactive parser and
> non-interactive parser? Thanks.

Doesn't bash in interactive mode use readline and let it do filename 
completions, and then bash parsing each finished line?

With a pull parser it might be able to show bash syntactic completions as well. 
Then it should not use LALR(1) which does not give the right tokens (it can do 
some reduction before arriving at it), but LAC, see the Bison manual, sec. 
5.8.3. It says though that that there may be a performance penalty. In general, 
most time is spent in the lexer and the actions, so only some profiling can 
tell whether that is of importance in the case of bash.