Add implicit tuples to . DSL

[gilch]

Something I mentioned in #911, Python code often passes tuples to the subscript operator [], in numpy code especially (for multidimensional slices), and now in the typing module's generics. Currently you can write things like,

;; foo[:, i]
(. foo [(, (slice None)
           i)])

;; Generator[User, None, None]
(. Generator [(, User None None)])

But since we're already declaring a list, the tuple seems redundant. So we could simplify it to.

;; foo[:, i]
(. foo[(slice None)
       i])

;; Generator[User, None, None]
(. Generator[User None None])

So a single item would be passed to the subscript as-is, but multiple items would implicitly have a tuple wrapped around them. In the rare case you actually want a single-item tuple, you can still do that explicitly, since it's a single item passed as-is.

;; foo[i,]
(. foo[(, i)])

In fact, the old syntax would still work as-is, even if the tuple had multiple items, since it would be a single item, passed as-is.

;; foo[i, j, k]
(. foo [(, i j k)])
;; same as
(. foo [i j k])

With more compact notation for slice objects, #541 we could improve the slice sytanx further.

I'm reluctant to propose anything that complicates the compiler. But there's really no reason the . DSL couldn't be a macro, provided a more basic .* special form for attribute access only. We could also add calls to the chain #1108.

[Kodiologist]

Looks pretty cool. It is a bit weird that square brackets, which are usually used to define a list, end up defining a tuple here. But the same criticism applies to Python, so that's not our fault.

[gilch]

Technically, it's the comma that makes a tuple in Python, not the parentheses (with the single exception of the empty tuple). It's just that syntactically, you often need them. Inside a subscript operator is one of the cases where you don't. But foo[(i, j, k)] is also valid Python.

[ekaschalk]

Somewhat related - how do you all feel about implementing ... as an alias for Ellipsis?

[gilch]

I just demonstrated that in #541. In the context of the tag macro, it's an alias. But dots do weird things to Hy expressions, since they interfere with our syntax for dotted lists. You can't just (setv ... Ellipsis). We'd have to special case it in the grammar the way Python does. I agree that spelling out Ellipsis makes slicing numpy arrays too annoying. You could (setv ,,, Ellipsis) though, which is my current workaround.

[vodik]

I managed to get hy to support Ellipsis:

hy 0.13.0+196.g0cd4df3 using CPython(default) 3.6.4 on Linux
=> ...
Ellipsis

Its actually a very small patch, I'll put up a PR shortly.

[allison-casey]

is this still relevant with the addition of ncut in #1968?

[Kodiologist]

Probably not.