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

[Sean Conner <sean@...>]

It was thus said that the Great Andrew Starks once stated:
> 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!)
> 
> 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.

  That's my reaction as well.  I just thought it might be fun to run with
the idea and jump into the deep end.

  -spc (Yeah, it could work, but I'd rather it not)