Re: Change #..., disallow #{}, add ...[]

[Dirk Laurie <dirk.laurie@...>]

2015-10-21 15:00 GMT+02:00 John Hind <john.hind@zen.co.uk>:
> On 20/10/15 03:10 PM, Dirk Laurie wrote:
>> 2015-10-20 18:34 GMT+02:00 Soni L. <fakedme@gmail.com>:
>>> On 20/10/15 02:00 PM, Andrew Starks wrote:
>>>> My biggest complaint, and it is a very small critique, is simply the
>>>> awkwardness of typing `select('#', ...)`. `#(...)` would be nicer to
>>>> type, but the implications of this are not known to me.
>>> `#...` would be nicer to type, `(...)` is an expression so `#(...)`
>>> actually returns the length of the first value in `...` (just like
>>> the current
>>> `#...`)
>> `##` would be even nicer to type.
>>
>> Tom has pointed out that my suggestion that #index becomes a `select`
>> shorthand when index is an integer is unimplementable, but for numeric
>> literals #1, #2 etc it is possible. (And in Ravi, of
>> course.)
>>
> [JH] IMHO  '#...' should be sugar for 'select(#, ...)' and '...[n]' sugar
> for '(select(n, ...))'.
> As well as being syntactically neater, this should allow implementation
> optimisations.

If it's just going to be a question of sugar, I don't think it is worth
the trouble. What bothers me is the sheer sloppiness of invoking
a function to do something so basic. The only possible reason, back
in Lua 5.1, must have been to avoid syntax bloat. The moment
we agree that some syntax increase can be tolerated, it may as well
be used to do the job neatly.

The token `...`, similarly, is forced on `select` because functions
communicate via argument lists. The moment some other syntax
is introduced, we can discard `...` (since the VM knows only one
VARARG) unless a future extension to Lua is envisaged in which
tuples are another type for which ... is a constructor.