Why does lpeg.d.tl define the LPeg's match() function twice? #1098

@pratikrath126 - Thanks for the explanation. I am familiar what LPeg pattern:match() can return in pure Lua. It is the Teal types that are new to me.

Is any... really a tuple? I thought tuples were declared as {any,any,any} (for example). And I thought Teal tuples were represented in Lua as Lua tables. I would have thought that a return type of any... would mean that the function returns zero or more (or perhaps one or more?) values of any type.

Can tuples have an indeterminate number of elements? (I.e. where the number of elements in the tuple is not known at compile time.) The Teal Book does not mention this, nor document a notation for specifying such a tuple type.

This Teal program compiles and runs:

local x : any = { 5 }
print ( x )

Whereas this program does not compile:

local x : any... = { 5 }    --  trying to declare a type that matches any tuple.
print ( x )

This program also does not compile:

local x : {any...} = { 5 }    -- trying to declare a type that matches any tuple.
print ( x )

Furthermore: It seems to me that number is a subset of any..., and therefore there is no benefit to having two definitions.

Put another way, if LPeg pattern:match() returns a number, we don't know whether (a) there were zero captures or (b) there was a single capture that happens to be a number.

What am I missing?

But the rest of the signature is the same? So unless I am missing something you always need to use as anyway. Or make some other promise to the compiler which it can't check.

Honestly, I would've expected this to be a compile error.

@parke any... is indeed not a true tuple but just saying that it can return any amount of values of any type.