[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Curiosity of decimal numbers followed by concatenation
- From: Eike Decker <zet23t@...>
- Date: Sun, 7 Feb 2010 19:18:59 +0100
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.
2010/2/7 KHMan <firstname.lastname@example.org>:
> Gé Weijers wrote:
>> On Sat, 2010-02-06 at 23:51 +0800, KHMan wrote:
>>> And can the above be parsed as valid Lua syntax in any way?
>> 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
> 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.
> Kein-Hong Man (esq.)
> Kuala Lumpur, Malaysia