Weekly WIPs (work in progress) are shorter posts that describe projects or features that are still being worked on, as opposed to fuller posts looking at completed work. Most features take weeks to build, so these are smaller intermediate progress reports, but hopefully will still be interesting!
While real electronics components have fixed number of pins (for example, a fixed 2-to-1 digital multiplexer: 2 input pins, 1 output pin), this becomes more of an implementation detail if we want to raise the level of abstraction of design. In fact, instead of thinking of fixed n-to-1 digital multiplexers and needing to worry about the specific n, it might be more natural to think about an arbitrarily-sized digital multiplexer.
And this is that port arrays tries to address: it allows the creation of a block (for example, DigitalMultiplexer) that has an array of arbitrary-length ports (for example, digital inputs). Viewed from outside that block, we can request as many instances of the port as needed. Viewed from inside the block, we can either specify a fixed number of ports (for example, a 2-to-1 digital multiplexer chip would only instantiate two input ports) or allow it to generate (for example, a multiplexer tree generator could create an arbitrarily large multiplexer out of several 2-to-1 chips). There would be some constraints (for example, you can't request 3 input ports from a 2-to-1 chip - well, you technically could with the HDL as described, but it should error out and ask you to choose a different implementation)
Making the Sausage
Now, ideas are great and all (actually, this one has been thought about since 2020), but building a major feature and adding new core semantics actually takes a lot of time and effort. In prior weeks (years actually), there has been a lot of thought on how this feature would behave with example cases and mockups - check out the GitHub issue linked above. Only recently have I nudged closer to implementation by writing up an engineering roadmap, thinking of how to structure it into the compiler (as opposed to just what it should do), and putting code down.
Red (failing) tests are not an unexpected sight during the development process
This week has been writing the frontend (Python HDL) code, associated unit tests (check it generates the right internal data structures), and compiler unit tests. Hopefully next week will see the compiler changes done, red tests going green (passing), and maybe even the microcontroller block refactored - which would be a major milestone for this feature.