Inline Bundle definitions

[UnsignedByte]

One thing that I've been having to design around pretty often is bundle ports. For example, in the fft, often times I need to have bundles of complex numbers, of which there are two main possibilities (for an array of 4 complex numbers):

// defining two bundles
bundle arr_real[4]: ['G, 'G+1] 32;
bundle arr_imag[4]: ['G, 'G+1] 32;
// defining one bundle, such that every two elements represents one number
bundle arr_pairs[8]: ['G, 'G+1] 32;

The former is much easier to mentally work with at least in my opinion, but it has one main annoyance. Say we define some operator on complex numbers. An easy and relatively clean way to do so is as follows:

comp ComplexAdd<'G: 1>(
    left[2]: ['G, 'G+1] 32, // stores the real and imaginary ports
    right[2]: ['G, 'G+1] 32,
) (
    out[2]: ['G, 'G+1] 32,
) {
    // ...
}

But this makes the first implementation of storing reals and imaginaries in two different arrays much more annoying to deal with, as, in order to use ComplexAdd, current syntax requires us to do the following:

bundle left[2]: ['G, 'G+1] 32;
left{0} = arr_real{0};
left{1} = arr_imag{0};
bundle right[2]: ['G, 'G+1] 32;
right{0} = arr_real{1};
right{1} = arr_imag{1};
comp_add := new ComplexAdd<'G>(left{0..2}, right{0..2});

It would be nice if we could define bundles using a {port, bundle_port{a..b}, ...} syntax (or similar) in a couple cases:

• When invoking an instance in port bindings, such as the case above, which could be replaced by

comp_add := new ComplexAdd<'G>({arr_real{0}, arr_imag{0}}, {arr_real{1}, arr_imag{1}});

• In bundle definitions, where we can immediately assign to a bundle as follows:

bundle left[2]: ['G, 'G+1] 32 = {arr_real{0}, arr_imag{0}};

With type inference, the [2] could even be eliminated as well, and in the future the syntax could look like

bundle left = {arr_real{0}, arr_imag{0}};

[rachitnigam]

Oh awesome, this seems super useful. I guess the best way of representing complex numbers would come from something like #99 but this seems orthogonally useful. I think the first syntax (with the explicit type annotation) would be easy to eliminate in the frontend but the second one would require type inference.

[rachitnigam]

@UnsignedByte this is marked as "needs triage" but it seems the design is clear: write this as an abstraction in the AST/frontend and compile it away by the time we get to the IR? Should we mark it as "available" or "blocked" depending on whether we consider it blocked on the AST redesign?