Re: Suggestion for 5.3: import() for creating a "slew" of locals

[Andrew Starks <andrew.starks@...>]

On Tuesday, November 19, 2013, Tim Hill  wrote:

On Nov 19, 2013, at 12:44 AM, Sir Pogsalot <sir.pogsalot@gmail.com> wrote:

 My mistake for making it seem like I was primarily arguing that locals are better for performance and this should be the biggest reason for having an import().  The main reason *is* brevity.  But if I say brevity I'm treated like I'm lazy, if I say efficiency I'm flooded with "well why not LuaJIT?", and no matter how many times I try to politely remind people I'm still reading suggestions involving _ENV.  I get it: For most cases touching _ENV works, but I do not agree that is is convenient or appropriate ALL the time.  I still get this overwhelming sense of "feature suggestion?  BURN THE WITCH" from this list. 

If your main reasons is brevity then I would agree some syntactic sugar does have some potential. I think, however, that you would still have to explicitly list every single item. That said, it would still make sense to do something like:

local from table.insert, table.delete, x, y.z.k

As sugar for:

local insert = table.insert

local delete = table.delete

local x = x

local k = y.z.k

This approach is pure sugar; as long as the list is explicit names then there is no conflict between compile-time and run-time knowledge, and you end up with cleaner code with almost no compiler overhead. The problems only arise if you try to impute the list from the run-time contents of tables.

As for burn the witch … One of the benefits of Lua is it’s adherence to “smaller is better”, which is good (imho). However, as with all such philosophies, there is always the danger of dogmatism. And yes, I think sometimes there is a little too much vociferous objection to suggestions here. This is a shame, as it tends to put off people making or supporting suggestions for new features, which in turn obscures which new features people actually do want. I admit I’ve pretty much given up on making suggestions here for that reason.

—Tim

There are two fun things to do on the Lua mailing list:

1. Contribute to the open source world by proposing or participating in a discussion on an improvement to the language. 

2. Understand that this is not an open development project and benefit  from the almost guaranteed feeling of satisfaction that comes from being right, when you shoot it down early.

All in jest, but stated for a point: Lua is not an open development project. We can all clamor and debate, but it's arm chair quarterbacking, until Team Rio says it isn't.

This is not a democracy and so these discussions are like two dudes on a beach; debating the hotness of a chick. They both are sometimes fun to have, should never be taken seriously and can quickly turn tedious. 

In our company, we do not make lots of open source stuff. The only people that get a vote on what we make are our staff and money. I'd love to say that we've been principled designers in every case.

However, the number of features that have built our reputation is fewer than the number that we regret having added. I cannot imagine the discipline required to curate a language and the cost of undoing damage, later.   

So, make your suggestions. But do it with the understanding that necessity, like beauty, is in the eye of the beholder. 

And sometimes, your chick is just not that hot. 

With apologies to the ladies...

-Andrew