lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


I don't think this is as easy as it looks at first
what about these cases if whitespaces would not be required:

1. -- number
.1 -- number
2..3 -- must be number concatenated
.2..3 -- same
.2...2 -- uh same
.2...2..3 -- still valid
.2...2...3 -- still valid ...
.2...2...3. -- dang, that's an error!
2...2...3. -- but that's ok again

And what about this ambiguity:

2...2 -- should this result in (2.)..(2) or (2)..(.2) when evaluated?

I have no doubt that a machine could solve this, but I don't think
that human readers are machines when it comes to remember what the
exact precedence is. I would rather prefer to have a custom error
message for such code than adding some extra code logic to the Lua
code parser that would only be used to please some corner-case test
that is (in my opinion) highly unlikely to occur in real code. I think
it's unnecessary effort - remember, one of Lua's main advantages is
that it is as tiny as it is right now.

Eike


2010/2/7 KHMan <keinhong@gmail.com>:
> Gé Weijers wrote:
>>
>> On Sat, 2010-02-06 at 23:51 +0800, KHMan wrote:
>>>>
>>>> 1.2.3.4.5e+say_cheese
>>>
>>> And can the above be parsed as valid Lua syntax in any way?
>>
>> [snip]
>> If you build a lexical scanner the textbook way, using an FSA the
>> resulting scanner would not do this. It's not a big issue, but if you,
>> like the original poster, need to parse Lua without using the lua.org
>> parsing routines you end up scratching your head.
>
> So, I guess there were engineering decisions that precluded a textbook
> implementation -- this is not uncommon in the canonical Lua implementation.
> Then again, EEs are used to using a lot of very quirky software and thus
> would just shrug at this. *shrug* :-)
>
> I think in general, anyone who wants to mess with corner cases should know
> full well that they are playing with a lot of rope, in case they slip and
> hang themselves... :-) Lua assumes you're more interested in working with
> readable programs rather than in giving a code reviewer a splitting
> headache.
>
> If a Lua coder doesn't feel safe with this, then they can use an editor that
> gives correct highlighting with such corner cases. SciTE works well, and if
> any Scintilla-based editor messes up with Lua syntax highlighting, ping
> their list and we will fix it.
>
> It is also easy to write a new lexer from a written specification of llex.c,
> if one wants an independent exact implementation.
>
> --
> Cheers,
> Kein-Hong Man (esq.)
> Kuala Lumpur, Malaysia
>