 |
lua-l archive |
|
|
||
|
steve donovan wrote:
On Tue, Aug 11, 2009 at 3:18 PM, Duncan Cross<duncan.cross@gmail.com> wrote:So, what do people think? Is it something you'd ever use? Is it just too ugly and weird?I think one meaning for ... is enough ;)
Steve, I can certainly see the argument against multiple meanings for the same tokens, though Lua (like most languages) has plenty of those already. And the reasoning is solid for truncation of return values as a default behavior in the contexts in which it currently happens. But the fact that we get many surprised queries about this behavior indicates that users expect to be able to capture all return values in the early part of an array initialization, etc. While I I don't see it as a big problem, it's still something that I could see myself using occasionally.
And I think { get_items()..., "no more" } is a clever solution. Being an ellipsis, the ... token has a relatively clear meaning in this context. It would take me a while to grok the implications in the parser and VM. But that's for the OP to do.
So I encourage you, Duncan, to try it out and share any results. Even if it doesn't work out, you (and we) will learn from it.
DougPS - I've always liked the phrase "elegant over clever" when considering an engineering/programming idea. I noticed that I used 'clever' above for something that Duncan labeled 'elegant'. I'm on the fence about this particular idea, but if its implementation is clean, I'd be happy to swing my mind towards 'elegant'!
______________________________________________________________________________________The information contained in this email transmission may contain proprietary and business sensitive information. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. Unauthorized interception of this e-mail is a violation of law. If you are not the intended recipient, please contact the sender by reply email and immediately destroy all copies of the original message.
Any technical data and/or information provided with or in this email may be subject to U.S. export controls law. Export, diversion or disclosure contrary to U.S. law is prohibited. Such technical data or information is not to be exported from the U.S. or given to any foreign person in the U.S. without prior written authorization of Elbit Systems of America and the appropriate U.S. Government agency.