[p5.strands] Refactoring scopes, adding If/Else Branches & For loops

[lukeplowden]

Increasing access

This issue discusses feature improvements which would increase access to new contributors by simplifying the current design

Most appropriate sub-area of p5.js?

• Accessibility
• Color
• Core/Environment/Rendering
• Data
• DOM
• Events
• Image
• IO
• Math
• Typography
• Utilities
• WebGL
• Build process
• Unit testing
• Internationalization
• Friendly errors
• Other (specify if possible)

Feature enhancement details

Currently, there is a primitive version of if statements working in p5.strands. It comes with some problems, especially that it's not possible to nest them. There is not currently any implementation of for (or while) loops.

ConditionalNode currently works in the non-transpiled version of p5.strands which does not include operator overloading, and the API looks a bit like this:

If(1.0 > 0.0, () => assign(myVar, 0))

However, the implementation is not really complete. Before continuing, I want to start some discussion about what features are considered useful for p5.strands.

At the same time, some of the ways which p5.strands was implemented originally made it difficult to get a prototype working. Namely, the current shader context is no very well fleshed out. In order to keep things in line with the rest of p5, I decided to use global variables.

// So we can do this:
() => {
  const time = uniformFloat(() => millis());
}
  // Instead of this:
(program) => {
  const time  = program.uniformFloat(() => millis());
}

When it comes to branches, something similar happens, in that assign() uses a global BRANCH variable which effectively gives the context of the branch (scope) that we're in.

I am wondering whether a considerable refactor would be helpful to simplify the implementation of scopes. BRANCH could be moved into GLOBAL_SHADER.context for a start, and renamed to current_scope. With some discussion about what features we want to design for in the future we can start to think about how to refactor.

This would be to help the future maintainability of p5.strands, as the current architecture feels slightly blocking at this point if we move forwards with conditionals and loops.