Local function declarations

[SpencerPark]

Functions don't really need to be restricted to the top level but they were to distinguish the fact that they do in their own namespace (a function and variable can share the same name). This is due to the very verbose syntax for function calls and the primitive like nature of all values.

The functions currently require the def keyword also to signify that they cannot be changed (but can be overloaded). Therefor they can be imported/exported very easily. In addition the complete separation from any context makes them trivial to pluck out of the scope they are defined in.

On the contrary, common functions like chorus or similar could benefit from being defined a couple times in various blocks instead of multiple top level chorus_piano, chorus_guitar, etc.

Scope considerations

1. Are functions defined within a block visible from other blocks? The namespace for the function is simply the block name so the fully qualified name is well defined and deterministic. From a user perspective this may be natural but from the compiler perspective this is a lot of overhead and complications that might never be worth it.
   • Constant functions with empty closure environments would be no problem to share
   • Non-empty closure environments with non-constant variable introduce the obvious race conditions with the implicit shared memory
   • These definitions may depend on the block's state and therefore must be defined at a certain point in time. Simply invoking a function has a race condition on the definedness of the function unless there is an implicit synchronization which is most likely too unnatural to impose.
2. Should function definitions be more like methods that have a super memory referencing the block it is defined in?
3. Functions defined in blocks as closures perhaps? This may be restricted to only allowed to reference constants in the super scope or it could take a snapshot as the initial value of a local variable in the function environment with the same name.

Other considerations

1. Are the forward references allowed as with the fields? Leaning towards no to keep things consistent with local variables. Similarly this would feel more like jumping around in time with the sequential nature of the block bodies.
2. Do they need to be constant?