This is particularly visible in the necessity of defining a main function in shaders. Functions serve no other purpose currently—there’s no mechanism to call them, for example—so it’s just another dynamically-checked error waiting to happen.

There’s no real way in Draw to retrieve the window size (except possibly by appeal to SDL2).

You declare & read uniforms in Shader, but set them in Draw. Since the declarations are in Shader, they aren’t visible in Draw, and so you have to use the same name essentially by coincidence.

It’d be better to bind them in Setup, use them in Shader, and set them in Draw.

It’s just a tree thus far, not actually anything describing a UI.

It seems to work alright for Add & friends, but for Bind & MulMV it returns mempty instead of recurring.

Bind is declared as:

data ShaderF a where
  Bind :: GLSLValue a => Var (Shader a) -> ShaderF (Var (Shader a))
  …

This leads me to think that the standalone deriving machinery isn’t clever enough to connect the dots between the Var (Shader a) argument and the Var (Shader a) return. Either way, the function passed to foldMap will be Var (Shader a) -> m.

MulMV is slightly weirder:

  MulMV :: Shader (Linear.V4 a) -> Shader a -> ShaderF a

(This comes about by way of needing a matrix & vector of things. We don’t want to take a literal matrix/vector, either, we want to take shaders of those types. Type-restricted recursion is tricky!)

Partly due to #11, Shader is needlessly imperative. These things are just functions!

It’s pretty easy to end up with stuff that doesn’t produce valid GLSL because of e.g. a ShaderF constructor with poorly-defined semantics.

There’s no way to get any kind of feedback. This is going to require events &c.

We don’t have any API docs or any documentation of the motivation of any of these approaches.

If you want to draw the vertices for a rectangle you have to:

1. Setup Make a list of the vertices.
2. Setup Make an array object to hold them, & copy them in.
3. Draw Bind the array.
4. Draw Figure out the indices & length you need.
5. Draw Figure out what drawing mode they were supposed to be drawn with.
6. Draw Issue the DrawArray command.

This is bad, and it gets much worse as soon as you add a second (and third, etc) rectangle. Add some other shape, or some other geometry arrangement (e.g. different mode), and 💥

You can write fragment shaders that expect inputs not provided by the corresponding vertex shader, and vertex shaders that provide outputs which the fragment shader doesn’t expect. (The latter may not result in a runtime error; I haven’t checked.)

In either case, we already reflect the inputs/outputs by defining shaders as functions, so it should be possible to enforce that the vertex shader’s output has the same type as the fragment shader’s input.

We’d like to be able to aggressively optimize languages by applying certain equalities to reduce the term tree. However, you can’t in general do optimizations (or more broadly, analyses) of languages in Freer, because Freer (being an encoding of >>=) has to perform its effects in order to traverse subterms. This is actually the mechanism by which some surface terms (e.g. stack & adjacent) operate.