[tensor-shapes] Should we allow multiple splats?

Open
#4,969 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
30/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Active
Tech stack
python, rust
Domain
compilers

Research direction

Start by tracing how type variable tuples, IntTuple shapes, and tuple unpack forms are represented and handled. Compare the existing tuple and IntTuple paths, then determine whether a shared representation can support multiple splats without making them diverge. Done means the design is agreed and multiple splats are supported consistently, with coverage for the examples described in the issue.

Written by the indexing model from the issue text.

Description

needs-discussion tensor-shapes

One of the things I noticed when I implemented support for IntTuple[*Elements[S], N] was that the limitation on type var tuple that there can only be one splat is artificial: we define type var tuple in a way where syntactically there can only be one in scope at a time (or at least mostly; I guess you could have one in scope at each of a class and method boundary but that's pretty artificial).

As a result, all the python type checkers I've looked at define unpack forms with only one splat.

But that's a completely artificial limitation, it makes perfect sense to splat arbitrarily many tuples into a new tuple, for example if we allow tuple splats in general then this is sensible:

def f[A: tuple, B: tuple](a: A, x: int, b: B) -> tuple[*Elements[A], int, *Elements[B]]

At the moment I'm not actually trying to support Elements for normal tuple anyway, but the same pattern can happen with IntTuple for shapes (and does happen - for example a sufficiently large cross-product might do this).

To handle this we'd have to change the representation to something like an array of tagged slots that can either be normal types or splatted types.

It is possible to make this change for just IntTuple without changing tuple, which would be less invasive, although the resulting implementation would be less coherent (ideally I don't want the types diverging too much). That's the main blocker: this isn't high enough priority for me to want to change tuple right now, but I also don't want the structures to diverge.

Inspired by a question from @TimothyEDawson in https://github.com/facebook/pyrefly/discussions/4807

Dominant language
Rust
Stars
7k
Forks
521
No merged PRs in 30d

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from facebook/pyrefly

All issues in facebook/pyrefly

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.