Nested tuple access can't parse

[andymcn]

Using "dot int literal" to access tuple elements cannot parse correctly for nested elements, because it looks like dot float literal.

Example, access element 2 in element 1 of tuple x:
x.1.2

This is intended to be the lexer tokens:
id x, dot, int literal 1, dot, int literal 2

However it is actually:
id x, dot, float literal 1.2

Possible solutions:

1. This can be worked around by putting a space anywhere between the 1 and the 2, eg:
   x.1 .2
   but that's pretty ugly.
2. Handle the dot float access when parsing. This will be really nasty.
3. Use a different syntax for tuple element access.
4. Do not allow nested tuples.

[sylvanc]

Sebastian suggests using array-like notation, eg:

var w = (1, 2, 3)
var x = w(0) // x == 1
var y = w(1) // y == 2
var z = w(2) // z == 3

That means basically getting rid of accepting a TK_INT as the right side of a TK_DOT, and in the type checker for TK_CALL, if the receiver is a tuple, we accept a single literal integer positional argument, which must be in-bounds.

Nested tuples just get nested calls:

var w = (1, 2, (3, 4))
var x = w(2)(1) // x == 4

[andymcn]

The only other sensible option I've come up with for this is to use a name that is not just an integer, a leading underscore would be the obvious choice:

var x = w._0
var x = w._2._1

but that's a bit ugly.

One thing, for the array style syntax, would the index have an be an actual literal, or would a constant expression be allowed? Eg:

var z = w(1 + 2)

[sylvanc]

The issue with a constant expression is we would then be lifting elements of code generation into the type checking phase, since we need the final value in order to make sure the index is in bounds and to get a type for the expression. That can be done, of course, but it would be a significant change, and could get complicated if we wanted to allow constant expressions that themselves required type checking (a function call that's actually a constant expression, etc).

Leading underscores are possible, that's what scala does:

http://stackoverflow.com/questions/6884298/why-is-scalas-syntax-for-tuples-so-unusual

And it's sort of what's done in LaTeX, since _ is subscript, so x_1 is x₁.

[andymcn]

Agreed, an actual literal int is required.

[sylvanc]

We went with leading underscores, and a 1 based index.