Re: Next Version of Lua?

[Mark Hamburg <mark@...>]

On Jun 10, 2009, at 3:02 AM, Olivier Hamel wrote:

> * (VM?) + Lexer: Have an explicitly defined handling of cases like  
> {[3] = 3, 1, 2, 3} and do not adjust the return codes to one unless  
> an operation is directly performed on it. Example:
> local tbl = {ReturnSixIncrementalValuesFromZeroToSix(), 7, 8, 9} --  
> this would equate to doing {1, 2, 3, 4, 5, 6, 7, 8, 9}
> local tbl = {ReturnSixIncrementalValuesFromZeroToSix() + 10, 7, 8,  
> 9} -- this would equate to doing {11, 7, 8, 9}
> The alternate suggestion of using ';' to elaborate when to use  
> multiple returns might be better (feedback on this please?)?

I'll let others discuss the pros and cons -- one of the big cons being  
compatibility -- but I will concur that it would be nice to have some  
sort of splicing construction for tables if only to allow for  
functions that returned nothing and didn't then insert a nil into the  
table which then tells ipairs that it's the end of the table:

ViewList = {
	Button( "I'm always here" ),
	Optional( TestCondition(), Button( "Condition Was True" ) )
	Button( "I'm always here too" )
}

The current work around for this is to have Optional return a "should  
not be here value" and have a post-process remove such values. One can  
also address splicing that way. But that doesn't feel quite as natural  
when building structures.

On the other hand, I don't know what syntax I would propose for this.  
It probably needs to stand out, but the more it stands out the more it  
risks not being used properly.

Mark