How should a language with period-based tuple indexing be parsed?

Question

A few languages, most notably Rust, have tuple-indexing syntax that looks like this:

tuple.0 // Access the first element of tuple

This syntax is quite similar to that for property access:

foo.bar()

Is it better to implement this as a separate parser rule, or to parse it as a property access, and add some special handling for the tuple type internally so that it returns the appropriate value?

Answer 1

One thing to note about this syntax for tuple field accesses, is that it can clash with the lexical syntax for floating-point or decimal numbers. In many languages (e.g. Java, Javascript and Python), .1 is a single token which means the number 0.1.

In this case, the source x.1 will be lexed as two tokens: an identifier x and a number .1; on the other hand, x . 1 will be lexed as three tokens. So the parser will need to handle both cases; this is messy, and possibly even ambiguous:

• If your language has function calls without parentheses, then f .1 also means calling the function f with the argument .1.
• If your language has casts with parentheses, then (T) .1 also means converting .1 to type T.

Therefore if you want this syntax for tuple field accesses, it's probably best to not allow decimal literals to begin with a decimal point. Rust, for example, gives the following syntax error if you write .1 instead of 0.1 where a number is expected:

error: float literals must have an integer part

Answer 2

You only need to parse it differently if it would be "in the cracks" between method accesses and field accesses. If you don't have that distinction you can parse them the same way.

In a language like Python where property access and method access are the same, simply allowing properties to start with a number during the parsing stage would be enough.

On the other hand, in a language where the difference between properties and methods needs to be known at parse time you need a more complex grammar. You would typically have a separate parser rule for all 4 cases. Something like:

method_call := expression "." identifier "(" argument_spec ")"
attribute_access := expression "." identifier
tuple_attribute_access := expression "." number
function_call := "(" expression ")" "(" argument_spec ")" | identifier "(" argument_spec ")"

There is no real possible confusion between method calls and attribute access. But the confusion between function calls combined with function calls and method calls requires breaking the syntax up in many different blocks, and thus will require special casing the tuple access.

This is why Rust allows tuple.0() but not struct.attribute().

If you don't have methods, disambiguate method vs property accesses later than parsing, or use a different syntax for methods than properties, you may not need to special case tuple access.

Answer 3

Unless the language defines something completely weird and orthogonal to other forms of accessing members, I'd use a parse rule beside the regular member access and create a tuple access AST node that has a common super type with the member access AST node. In essence, it's just a record with implicit names taken from integer literals.