Re: Allow table.keyword rather than table['keyword']?

[Andrew Starks <andrew@...>]

On Mon, Mar 14, 2016 at 3:32 PM, Sean Conner <sean@conman.org> wrote:
> It was thus said that the Great Roberto Ierusalimschy once stated:
>> > Unless I'm missing something, this wouldn't result in any ambiguous
>> > syntax. An identifier, followed by a . or :, followed by a keyword, is
>> > never valid syntax under current rules, so treating the keyword in
>> > that sequence of tokens as an identifier shouldn't cause problems.
>> >
>> > So I'm +1 on this. It would be nice to have the ability to do things
>> > like _G.end (or _ENV.end). Again, unless I'm missing something (which
>> > I very well might be given that I'm currently recovering from a cold
>> > that's screwing with my thinking a bit).
>>
>> If not causing ambiguity is a good enough reason, why stop at reserved
>> words? We could as well add all the other tokens, too. None of them
>> cause ambiguities:
>>
>>   _G.*  _G.%  _G.>=  _G.<  _G.==  _G.(  _G.]  _G:)
>
>   My initial reaction was "Gaaaaah!  Nooooooo!" but upon further reflection,
> this might be okay.  You could change the names of the metamethods:
>
>         mt.+ = function(a,b) ... end            -- __add
>         mt.* = function(a,b) ... end            -- __mul
>         mt.[ = function(t,k) ... end            -- __index
>         mt.] = function(t,k,v) ... end          -- __newindex
>         mt.# = function(t) .. end               -- __len
>         mt.: = function(self,...) ... end       -- __call
>         mt.} = { ... }                          -- __metatable
>         mt." = function(self) ... end           -- __tostring
>         mt.== = function(a,b) .. end            -- __eq
>         mt.{  = function(...) ... end           -- __pairs
>         mt.@ = "name"                           -- __name
>
>   -spc (Yeah, that could work!)
>
>


This comes down to a discussion about changing the syntactic sugar,
removing the restriction that when accessing a field with the
`table.name` notation, the `name` must also be a valid variable name.

It is hard for me to predict the impact of a change like this, but I
think that it would likely make the language worse. There is a lot of
good that happens when limitations are put in place for the purpose of
stopping people from writing code that is hard to follow. Just two
sources of queasiness that I've come up with:

1: One would need to be more careful about searching for field names,
either manually or if you were writing a scanner / tokenizer. Writing
a robust scanner isn't much harder, but dumb scanners found in
programs like Sublime or some other editor that is only kind of "Lua
aware" would still miss-color `end` and other keywords-used-as-fields.
Still, manually reading code that uses a library that makes use of
`and` or `end` as field names would be jarring, no matter what.

2: `_ENV.> = 3` Maybe it doesn't matter that values in the `_ENV`
table are no longer *always* accessible as regular variables, but it's
a blemish that wasn't there before. Maybe others would see it as a
feature?

My guess is that Roberto's answer was meant to be illustrative of
where this would lead and to suggest that it may not be a very
readable and clear place.

-Andrew Starks