Lua 5.4 local attribute syntax whitespace sensitivity

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Lua 5.4 local attribute syntax whitespace sensitivity

Sergey Zakharchenko
Hello,

As far as i understand, the current (5.4.0) parser requires a space
after the attribute's closing '>' if it's followed by a '=', resulting
in an error "'>' expected near '>='" when parsing e.g. "local
a<close>=f()". I don't mind that too much, but it seems a bit
inelegant to me. Is it going to stay this way, or will the construct
without a space be allowed eventually?

Best regards,

--
DoubleF
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4 local attribute syntax whitespace sensitivity

Soni "They/Them" L.


On 2020-08-19 12:36 p.m., Sergey Zakharchenko wrote:
> Hello,
>
> As far as i understand, the current (5.4.0) parser requires a space
> after the attribute's closing '>' if it's followed by a '=', resulting
> in an error "'>' expected near '>='" when parsing e.g. "local
> a<close>=f()". I don't mind that too much, but it seems a bit
> inelegant to me. Is it going to stay this way, or will the construct
> without a space be allowed eventually?

actually, it's the lexer that requires it. while it could probably be
done, it'd require a completely different parser design.
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4 local attribute syntax whitespace sensitivity

Sergey Zakharchenko
Soni,

Soni "They/Them" L. <[hidden email]>:
> actually, it's the lexer that requires it. while it could probably be
> done, it'd require a completely different parser design.

Or, as it seems, a small but very dirty trick:)

Best regards,

--
DoubleF
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4 local attribute syntax whitespace sensitivity

Philippe Verdy-2
In reply to this post by Soni "They/Them" L.
Even if the lexer creates a single lexeme for ">=", the parser could still accept it as a fallback but this requires splitting parsing rules for matching the next "=" within the context of use (an assignment statement). This may seem inelegant, but that's what is done actually in complete parser s that would have to work around would would be otherwise a syntax error with an unexpected token.

However you could as well drop the ">=" token and always treat it as two tokens (optionally separated by spaces/comments) without creating syntaxic ambiguities in expressions expecting the binary comparator. just consider, this code:

  if x > = 0 then
  end

Is it really ambiguous for programmers and more difficult to parse ?

As well for other diagrams used in operators, which could be parsed more leniently by allowing them to be split by optional whitespaces/comments In fact it could simplify the lexer, with a very modest slowdown for the parser as it will read, and shift a few more tokens in an automata which is a bit larger in terms of total number of states.

If you don't do that, yes there programmers have to use explicit whitespace separators between ">" terminating an attribute and the "=" sign marking an assignment. This is minor because usual conventions recommend separating "=" in assignments for formatting the code.

This is then a very minor issue we can live with.


Le mer. 19 août 2020 à 17:39, Soni "They/Them" L. <[hidden email]> a écrit :


On 2020-08-19 12:36 p.m., Sergey Zakharchenko wrote:
> Hello,
>
> As far as i understand, the current (5.4.0) parser requires a space
> after the attribute's closing '>' if it's followed by a '=', resulting
> in an error "'>' expected near '>='" when parsing e.g. "local
> a<close>=f()". I don't mind that too much, but it seems a bit
> inelegant to me. Is it going to stay this way, or will the construct
> without a space be allowed eventually?

actually, it's the lexer that requires it. while it could probably be
done, it'd require a completely different parser design.
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4 local attribute syntax whitespace sensitivity

Coda Highland
In reply to this post by Sergey Zakharchenko


On Wed, Aug 19, 2020 at 10:43 AM Sergey Zakharchenko <[hidden email]> wrote:
Soni,

Soni "They/Them" L. <[hidden email]>:
> actually, it's the lexer that requires it. while it could probably be
> done, it'd require a completely different parser design.

Or, as it seems, a small but very dirty trick:)


The small but dirty trick is how C++ decided to do it. It's... just kinda awkward.

/s/ Adam 
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4 local attribute syntax whitespace sensitivity

Roberto Ierusalimschy
In reply to this post by Sergey Zakharchenko
> As far as i understand, the current (5.4.0) parser requires a space
> after the attribute's closing '>' if it's followed by a '=', resulting
> in an error "'>' expected near '>='" when parsing e.g. "local
> a<close>=f()". I don't mind that too much, but it seems a bit
> inelegant to me. Is it going to stay this way, or will the construct
> without a space be allowed eventually?

I liked the "eventually" in this question :-)

  e·ven·tu·al·ly
  adverb

    in the end, especially after a long delay, dispute, or series of
    problems.

-- Roberto
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4 local attribute syntax whitespace sensitivity

Gavin Wraith
In message <[hidden email]>
          Roberto Ierusalimschy <[hidden email]> wrote:

> I liked the "eventually" in this question :-)
>
>  e·ven·tu·al·ly
>  adverb
>
>    in the end, especially after a long delay, dispute, or series of
>    problems.

But I thought you were from Rio, not Barcelona.
[For Fawlty Towers fans only]
--
Gavin Wraith ([hidden email])
Home page: http://www.wra1th.plus.com/
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4 local attribute syntax whitespace sensitivity

Petite Abeille


> On Aug 19, 2020, at 16:09, Gavin Wraith <[hidden email]> wrote:
>
> But I thought you were from Rio, not Barcelona.
> [For Fawlty Towers fans only]

https://www.youtube.com/watch?v=l6CKSW9I1cA