# Table dot number?

38 messages
12
Open this post in threaded view
|

## Table dot number?

 Maybe a stupid question, but what is the reason for which the following is not allowed? local t = {} t.1 = 3 -- why not t["1"] = 3 ? Thanks
Open this post in threaded view
|

## Re: Table dot number?

 On Thu, Oct 20, 2011 at 6:18 PM, KR <[hidden email]> wrote: > Maybe a stupid question, but what is the reason for which the following is not > allowed? > > local t = {} > t.1 = 3 -- why not t["1"] = 3 ? Because it's ambiguous? A newer Lua coder might expect instead: t.1 = 3 --> t[1] = 3 -- - Patrick Donnelly
Open this post in threaded view
|

## Re: Table dot number?

 In reply to this post by Krunal Rao If we are already discussing syntax- I always wondered why "%i":format(1) is invalid and needs to be written as ("%i"):format(1) Would the short form introduce ambiguities? Or is it more one of those "it just turned out that way"- things?
Open this post in threaded view
|

## Re: Table dot number?

 On 10/20/11 5:37 PM, Wolfgang Pupp wrote: > If we are already discussing syntax- > > I always wondered why > "%i":format(1) > is invalid and needs to be written as > ("%i"):format(1) > > Would the short form introduce ambiguities? Or is it more one of those > "it just turned out that way"- things? Just guessing here, but if one allows "%i":format(i) -- the following should also be allowed: "%i".format(wellWhatever) -- properly written: "%i".format("%i", i) -- but it does not matter as "%i".something is probably ambiguous to the parser, or maybe left out as someone might accidently forget to put one more dot when concatenating: "%i"..format(somethingElse) There's probably an answer somewhere here in the mailing list, but not one that can be easily found
Open this post in threaded view
|

## Re: Table dot number?

 In reply to this post by Patrick Donnelly Patrick Donnelly batbytes.com> writes: > Because it's ambiguous? A newer Lua coder might expect instead: > > t.1 = 3 --> t[1] = 3 I understand, but what is the exact rule for what is allowed after the dot? Same rules as names for variables? Thanks
Open this post in threaded view
|

## Re: Table dot number?

 On Fri, Oct 21, 2011 at 10:54 AM, KR <[hidden email]> wrote: > I understand, but what is the exact rule for what is allowed after the dot? Same > rules as names for variables? That's exactly it, 1 is not a valid identifier, so you cannot use the sugar that says that t.x == t["x"].  It's consistent with things like { [0] = 1 } in table constructors steve d.
Open this post in threaded view
|

## Re: Table dot number?

 On Fri, 21 Oct 2011 10:58:35 +0200, steve donovan wrote: > That's exactly it, 1 is not a valid identifier, so you cannot use the > sugar that says that t.x == t["x"]. Actually that's really the problem for me, rather than what is allowed in identifiers.      ('t.x == t["x"]'):gsub('x','1')      -- => 't.1 == t["1"]', not 't.1 == t[1]'
Open this post in threaded view
|

## Re: Table dot number?

 In reply to this post by Patrick Donnelly > Because it's ambiguous? Actually it isn't. I thought about it, and in fact I didn't find a good reason other than explaining historically from the way static typed languages worked and constructed our minds how we think and design languages.
Open this post in threaded view
|

## Re: Table dot number?

 >> Because it's ambiguous? > Actually it isn't. >From the language grammar point of view, it is ambiguous. But from the programmer point of view, it is. I think most people would expect t.1 == t[1], but the parser would assume t.1 == t["1"]. The dot syntax is a syntax sugar to have named fields in a table. And I can't find a real world situation were t.1 (meaning t["1"]) could be useful. You can still use t.f1, t._1, ... if you want.
Open this post in threaded view
|

## Re: Table dot number?

 > From the language grammar point of view, it is ambiguous. Sorry, I wanted to wrote that it is not!
Open this post in threaded view
|

## Re: Table dot number?

 In reply to this post by steve donovan On Fri, Oct 21, 2011 at 9:58 AM, steve donovan <[hidden email]> wrote: > On Fri, Oct 21, 2011 at 10:54 AM, KR <[hidden email]> wrote: >> I understand, but what is the exact rule for what is allowed after the dot? Same >> rules as names for variables? > > That's exactly it, 1 is not a valid identifier, so you cannot use the sugar that > says that t.x == t["x"]. > > Â It's consistent with things like { [0] = 1 } in table constructors > > steve d. > > In addition, you cannot use Lua keywords after the dot, like 't.end' or 't.for' - even though they *could* always be unambiguously distinguished from proper keywords in this context. -Duncan
Open this post in threaded view
|

## Re: Table dot number?

 On 21/10/2011 11.37, Duncan Cross wrote: > In addition, you cannot use Lua keywords after the dot, like 't.end' > or 't.for' - even though they *could* always be unambiguously > distinguished from proper keywords in this context. Or symbols, that would pose harder/impossible problems. t..    -- ? t["."] -- ok --    Enrico
Open this post in threaded view
|

## Re: Table dot number?

 In reply to this post by Patrick Rapin One can argue for minimalism of the parser or "because its the way the parser is written". Or would we really gain for allowing it? But From a point of grammar it is unambiguous. Any token beginning with a 0-9 is always a number, and never an identifier or string. There isn't a good reason why it should be different after a '.'. Really I started 3 times to write an answer to KR, why this obviously wrong, but discovered my reasoning would be flawed. Then I came to the conclusion, actually he has a point. On Fri, Oct 21, 2011 at 11:30 AM, Patrick Rapin <[hidden email]> wrote: >>> Because it's ambiguous? >> Actually it isn't. > > >From the language grammar point of view, it is ambiguous. > But from the programmer point of view, it is. > I think most people would expect t.1 == t[1], but the parser would > assume t.1 == t["1"]. > The dot syntax is a syntax sugar to have named fields in a table. > And I can't find a real world situation were t.1 (meaning t["1"]) > could be useful. You can still use t.f1, t._1, ... if you want. > >
Open this post in threaded view
|

## Re: Table dot number?

 In reply to this post by Krunal Rao On Thu, Oct 20, 2011 at 11:18 PM, KR <[hidden email]> wrote: > local t = {} > t.1 = 3 -- why not t["1"] = 3 ? What about t.1.3 - would you expect that to be t["1.3"] or t["1"]["3"]?
Open this post in threaded view
|

## Re: Table dot number?

 2011/10/21 Duncan Cross On Thu, Oct 20, 2011 at 11:18 PM, KR <[hidden email]> wrote: > local t = {} > t.1 = 3 -- why not t["1"] = 3 ? What about t.1.3 - would you expect that to be t["1.3"] or t["1"]["3"]? Or t[1][3]?
Open this post in threaded view
|

## Re: Table dot number?

 In reply to this post by Duncan Cross >> t.1 = 3 -- why not t["1"] = 3 ? the same as t.a.b Its interesting what straws people pull, because something sound unfamiliar, instead of opening their minds and rethinking something.
Open this post in threaded view
|

## Re: Table dot number?

 Oh no, you mean the '.' as the decimal point. ... Oh yes, that indeed opens up unambitious. I take the last email back. On Fri, Oct 21, 2011 at 12:26 PM, Axel Kittenberger <[hidden email]> wrote: >>> t.1 = 3 -- why not t["1"] = 3 ? > > the same as t.a.b > > Its interesting what straws people pull, because something sound > unfamiliar, instead of opening their minds and rethinking something. >
Open this post in threaded view
|

## Re: Table dot number?

 In reply to this post by Duncan Cross > >> I understand, but what is the exact rule for what is allowed after the dot? Same > >> rules as names for variables? > > > > That's exactly it, 1 is not a valid identifier, so you cannot use the sugar that > > says that t.x == t["x"]. > > > [...] > > In addition, you cannot use Lua keywords after the dot, like 't.end' > or 't.for' - even though they *could* always be unambiguously > distinguished from proper keywords in this context. A detail: This is not "in addition"; it is exactly the same rule. "end" is not a valid identifier. -- Roberto
Open this post in threaded view
|

## Re: Table dot number?

 Thank you all for your replies! I was not criticizing the decision, I just wanted to understand what was the correct syntax rule was ;) KR On 21 October 2011 17:07, Roberto Ierusalimschy <[hidden email]> wrote: >> >> I understand, but what is the exact rule for what is allowed after the dot? Same >> >> rules as names for variables? >> > >> > That's exactly it, 1 is not a valid identifier, so you cannot use the sugar that >> > says that t.x == t["x"]. >> > >> [...] >> >> In addition, you cannot use Lua keywords after the dot, like 't.end' >> or 't.for' - even though they *could* always be unambiguously >> distinguished from proper keywords in this context. > > A detail: This is not "in addition"; it is exactly the same rule. "end" > is not a valid identifier. > > -- Roberto > >