Add support for passing arrays as uniforms

[TheSeamau5]

There is a design choice here on whether to use Elm Arrays or Elm Lists to do this, but, the essence is that you'd want the following to be possible:

uniform vec3 myVectorArray[MY_VECTOR_ARRAY_LENGTH];

In GLSL, uniform arrays must be of fixed size and that size must be declared at compile-time and therefore the length of the array must be computed at run-time in order to compile the program. This could trigger dynamic recompilation of the shader if the Array were to change size.

[johnpmayer]

Currently conflicted on this. Compiling shaders is expensive, so I wouldn't want to introduce that as a best practice. I know that one of your use cases is the ability to add multiple lights. In practice, what happens?

1. Recompile shaders as the number of lights in your scene changes
2. Have a fixed length array of lights, so you can have up to N lights?

I admit I don't know much about where/why arrays are used in WebGL and am unfamiliar with best practices here.

Just so you're aware, I really don't want to break the current "guarantee" that you never get a runtime exception from missing attributes. Imagine if I passed in either an empty List or empty Array, but my shader expects a non-empty sequence. So homogenous tuples really might be the best fit in the interim that Elm doesn't have first-class fixed-length sequences.

[TheSeamau5]

I understand. Yeah, I've lately been searching the interwebs and I don't seem to see like there is much of a consensus. I'm not an expert in WebGL which is why I've decided to see what others have done.

Seems like the threejs guys bumped into this problem a few years back.
Their solution was just to put this flag at the API level so that the users figure out the best course of action. Basically, how it works is that if the user is ever gonna do something funky like change the size of an array which is passed as a uniform, they should set material.needsUpdate to true to tell Three.js to actually recompile the shaders.

This problem seems to be really common, as in here and here, although the latter has just a tiny mention about the dynamic compilation of shaders.

I know that the guarantee of types is super duper important because it allows for the awesome feature that the compiler can yell at you for not sending the right types to the GPU (which saves headaches cuz I've come to realize how bad the error messages, if any, from the GPU are).

That said, the problem with tuples, unless I'm missing something, is that its much harder to work with cuz every tuple is fundamentally a different type. I'm not an FP ninja, but how do you pattern-match on an n-tuple when n is unknown?

I'm leaning more on passing Array and warning users to exercise caution when using them. Like, if you pass an empty array, you'd get the MAX_ARRAY_LENGTH set to 0 and should warn users to use if statements or if-def guards when working with arrays.

Pity GLSL doesn't have Maybe, that would've helped us in this case.