Re: [TCLCORE] TIP 282 status

[Peter S <pet...@gm...>]

On 14/02/2017, avl <av...@lo...> wrote:
>
> Such a "look ahead" just isn't ever going to happen, because it
> cannot be done correctly.

To me it seems plausible. But of course the 'lookahead' needs to be
intelligent, not just a simple scan for '=' char, as that would fail.
So in essence, the 'lookahead' needs to include a full parser... Or
maybe it's better to do the decision after the whole expression is
available as a parse-tree, because then sub-expressions and operators
are already parsed. Well, probably that's the only way this would be
working properly, because to tell where are the assignments, the whole
thing need to be parsed first...

To illustrate, it should also handle such expressions correctly:

    { a( pow( a("=") = 2, a("(") = 4 ) ) = 1 }

means, set index "=" in array 'a' to 2, set index "(" in array 'a' to
4, then calc 2**4 = 16, and put 1 into array 'a' index '16' ... Which
won't be parsed correctly with a trivial lookahead.

But after parsing the above, parse tree should look something like
this (monospaced ascii drawing):

               =
              / \
             /   \
            /     \
           a()    1
            |
          pow()
           / \
          /   \
         /     \
        /       \
       /         \
      =           =
     / \         / \
    /   \       /   \
  a()    2    a()    4
   |           |
  {"}         {(}

If this is already parsed, the only difference is that the left-branch
of every '=' operator needs to be treated as array name, not as a
function call. No ambiguity in the parse tree. If this is available,
then you don't even need to mess with lookahead... That's messy and
needs a full-depth parser anyways to work correctly.

So, IMO, it may work.