In particular it may be useful to think about whether Roto will have a mutable state (as discussed in #245).
In which case, maybe a distinction between “pure functions” and “procedures” could be considered.
A procedure would be a list of statements. These statements may include modifying global state or performing IO.
A function would be an expression. It has access only to the arguments it has been passed. It does not call procedures.
Nim is a language that implements this distinction (as well as any FP).
If Roto were to be used similar to Lua, a mutable state on the Roto side is a must. But for use-cases like that of Rotonda this would cause problems with parallelization.
By making the distinction you are guaranteed that functions are safe to use in parallel. You could even perform memoization of their results.
These kinds of major design choices (top-level code, mutable state, classes, anonymous top-level functions) will inevitably shape the syntax.