Re: Lua parsing question

[Dibyendu Majumdar <mobile@...>]

On Thu, 27 Feb 2020 at 13:28, Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
>
> > The parsing and code generation of assignment statements is IMO one of
> > the trickiest aspects of Lua, another being the handling of multiple
> > return values. Lua solves the l-value / r-value dilemma by deferring
> > the resolution of these expressions until the expression is used -
> > hence the VINDEXED expression type can end up being a GET or a PUT.
> >
> > The parsing of assignments follows a strange course. I believe the
> > vars on the left of '=' are parsed recursively first, then at the top
> > of recursion, the expression list to the right of '=' is parsed, and
> > then during the unwind, the store instructions get generated. Please
> > correct me if I am wrong.
>
> Note that all this complexity is mainly due to LL(k) parsing and the
> absence of an AST. With an LR parser and/or an AST, the implementation
> would be able to follow the grammar almost literally. (What parsing
> technique does your new implementation use?)
>

There is no problem during parsing or AST construction, which is
straight-forward as you mention.
The AST for assignment statement is parsed into a struct such as:

struct node {
   var_list;
   expr_list;
}

At the moment I am generating code in three steps:

1. Generate code for the var_list.
2. Generate code for the expr_list.
3. In reverse order generate store instructions.

In step 3, I am converting load instructions produced in step 1 to
store instructions.
This appears to work, but causes spurious register usage.
To avoid that I can't see a way other than implementing delayed
resolution of 'load/store' for the var expressions.

Am I missing a trick here? Is there a better way?

Regards
Dibyendu