[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [Suggestion] Define t[[]] to index t with a long string
- From: Coda Highland <chighland@...>
- Date: Fri, 9 Oct 2015 07:22:46 -0700
On Fri, Oct 9, 2015 at 4:17 AM, Rena <firstname.lastname@example.org> wrote:
> On Oct 9, 2015 6:41 AM, "Thomas Jericke" <email@example.com> wrote:
>> On 10/09/2015 12:48 AM, Nagaev Boris wrote:
>>> t[[[z]]] looks ambiguous. Everybody would have to remember what it
>>> means: t("z") or t["z"].
>> t[[z]] is t("z") so t[[]] would actually be t(""), wouldn't it?
> Yeah, this syntax is ambiguous. t [[[z]]] already looks like it could be
> parsed as one of:
> t["z"] -- replacing innermost [] with ""
> t"[z"] -- replacing first [[ and ]] with ""
> t"[z]" -- replacing outermost [] with ""
> As far as neatness, I think spaces improve it a lot here by clearly defining
> the intended meaning:
> t[ [[z]] ] -- or even:
> [[some long string here]]
> But of course spaces don't matter to the compiler.
> My solution if I were presented with this situation would be one of:
> local s=[[z]]
> X = t[s]
> Or: refactor so that indexing a table with a string that doesn't fit nicely
> in quotes is no longer necessary. :)
Spaces DO matter to the compiler. It may recognize some tokens without
whitespace in between, but it most certainly does NOT allow whitespace
WITHIN a token.
Besides, I don't know if anyone's actually TESTED what Lua does here.
I just did:
Lua 5.1.5 Copyright (C) 1994-2012 Lua.org, PUC-Rio
stdin:1: unexpected symbol near ']'
> print[[ [x] ]]
In other words, the parse it ACTUALLY takes is: print"[x"]
This comes to no surprise to me because I've written a compiler
before; the lexer is doing greedy matching, extracting the longest
token it can from the stream.