Introduce a Tuple type

[masak]

Python has one, and for good reasons. It's a sequential type whose values can't be modified after creation.

Syntax:

()        # 0-tuple
(1,)      # 1-tuple (NOTE! Trailing comma!)
(1, 2)    # 2-tuple
          # ...you get the idea

Parsing-wise, we don't know when we see the opening ( whether we'll get a Q::Term::Tuple or a Q::Group. But that's no problem; we can just provisionally assume everything's the former and a comma-separated list of <EXPR> with trailing commas allowed — and if all we find is a single element and no trailing comma, we downgrade it to the latter.

From the Python language reference:

A parenthesized expression list yields whatever that expression list yields: if the list contains at least one comma, it yields a tuple; otherwise, it yields the single expression that makes up the expression list.

And here is the parser source, which seems to also work like that, at least when I squint.

We also don't have Q::Group yet. I think it's time to add it; a number of other issues hint that we should have one. The implementation of Q::Group would be very transparent and essentially just delegate to its contained node. The projected value is that language extenders might be able to hang semantics off of it.

[vendethiel]

C parsers are truly a sight for sore eyes...

[masak]

Tuples are the obvious thing we should get back when we introspect a parameter list of a function or macro.

Another nice thing about tuples is that we can hash on them; still undecided on exactly how hashing should work for things like dicts and sets.

[masak]

I for one wouldn't mind a zip builtin once we have tuples, so we can get up to all kinds of fun such as this:

for zip(keys, values) -> t {
    my key = t[0];
    my value = t[1];
    say("key: " ~ ~t[0] ~ ", value: " ~ ~t[1]);
}

And later, when we can destructure over tuples, even better:

for zip(keys, values) -> (key, value) {
    say("key: " ~ ~key ~ ", value: " ~ ~value);
}

(And, with #281, we get rid of those pesky prefix:<~> ops.)

[masak]

I was curious what Python does with map (and filter) on tuple types. Well, in Python 2 it works, but the result is a list:

Python 2.7.13 (default, Nov 24 2017, 17:33:09)
>>> map(lambda x: x * 2, (1, 2, 3))
[2, 4, 6]

In 007 I think we should support map and filter on tuples too, but we might as well give back a tuple. Python 2 cannot really do this, because map and filter are functions, which are meant to have a predictable return type.

Python 3 avoids this problem, however:

Python 3.5.3 (default, Jan 19 2017, 14:11:04
>>> map(lambda x: x * 2, (1, 2, 3))
<map object at 0x7f851e354668>

You get an iterator back, which you then have to either iterate directly, or explicitly cast to whatever sequence you want.

This is the first time I'm impressed rather than annoyed by Python 3's "you always get iterators back" tendency. But it remains to be seen whether we copy Python 3's design, or just return back the same type we got.