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

[Sean Conner <sean@...>]

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!)