Table dot number?

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Table dot number?

Krunal Rao
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


Reply | Threaded
Open this post in threaded view
|

Re: Table dot number?

Patrick Donnelly
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

Reply | Threaded
Open this post in threaded view
|

Re: Table dot number?

Wolfgang Pupp-2
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?

Reply | Threaded
Open this post in threaded view
|

Re: Table dot number?

Dimiter 'malkia' Stanev
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

Reply | Threaded
Open this post in threaded view
|

Re: Table dot number?

Krunal Rao
In reply to this post by Patrick Donnelly
Patrick Donnelly <batrick <at> 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





Reply | Threaded
Open this post in threaded view
|

Re: Table dot number?

steve donovan
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.

Reply | Threaded
Open this post in threaded view
|

Re: Table dot number?

Pierre Chapuis
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]'


Reply | Threaded
Open this post in threaded view
|

Re: Table dot number?

Axel Kittenberger
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.

Reply | Threaded
Open this post in threaded view
|

Re: Table dot number?

Patrick Rapin
>> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Table dot number?

Patrick Rapin
> From the language grammar point of view, it is ambiguous.
Sorry, I wanted to wrote that it is not!

Reply | Threaded
Open this post in threaded view
|

Re: Table dot number?

Duncan Cross
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

Reply | Threaded
Open this post in threaded view
|

Re: Table dot number?

Enrico Colombini
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

Reply | Threaded
Open this post in threaded view
|

Re: Table dot number?

Axel Kittenberger
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.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Table dot number?

Duncan Cross
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"]?

Reply | Threaded
Open this post in threaded view
|

Re: Table dot number?

Victor Young


2011/10/21 Duncan Cross <[hidden email]>
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]?
Reply | Threaded
Open this post in threaded view
|

Re: Table dot number?

Axel Kittenberger
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.

Reply | Threaded
Open this post in threaded view
|

Re: Table dot number?

Axel Kittenberger
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.
>

Reply | Threaded
Open this post in threaded view
|

Re: Table dot number?

Roberto Ierusalimschy
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

Reply | Threaded
Open this post in threaded view
|

Re: Table dot number?

Krunal Rao
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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Table dot number?

Philippe Lhoste
In reply to this post by Roberto Ierusalimschy
On 21/10/2011 18:07, Roberto Ierusalimschy 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.
>
> A detail: This is not "in addition"; it is exactly the same rule. "end"
> is not a valid identifier.

Since I was about to make the same remark, I perceived it as "in addition to the above
remarks", not in addition to the rule... :-)

--
Philippe Lhoste
--  (near) Paris -- France
--  http://Phi.Lho.free.fr
--  --  --  --  --  --  --  --  --  --  --  --  --  --


12