Lifecycle issue: update() called before setup() upon startup

[triss]

Bug
update() is called before setup() upon startup. update() should not be called until after setup() has been completed.

To Reproduce

require("L5")

function setup()
	v = 1
end

function update()
	v = v + 1
end

Expected behavior
v should increment.
first setup should be called where v is defined, then update should increment v.

Observed behaviour
Instead we get an error stating v has not been defined.
update() is called before v is defined in setup()

main.lua:8: attempt to perform arithmetic on global 'v' (a nil value)

Traceback

[love "callbacks.lua"]:228: in function 'handler'
main.lua:8: in function 'update'
L5.lua:178: in function 'update'
L5.lua:46: in function <L5.lua:15>
[C]: in function 'xpcall'

Platform:

• OS: MX Linux
• L5 Version: 0.1.7/0.1.8

[triss]

I can see several solutions to this:

1. split L5 internal updates from calls to users' update(), see Fix: update() called before setup() on startup #27
2. gate update() call until after setup() has run.
3. remove update() as a special callback entirely, see Remove update() from the L5 lifecycle #28

Arguments for removing update() callback

Align with P5 design

Typically P5 implementations do not have update() as part of sketch life-cycles. That model likely places less pressure on new users learning it. They do not need to understand when update() is called nor do they end up asking them selves questions about what is or isn't valid code in update() (eg. can I draw in update() or just in draw())?

The P5 lifecycle looks likes this:

setup()
draw()
draw()
draw()
...

L5 currently looks like this:

update()
setup()
draw()
update()
draw()
...

Navigating the code structure around update() was surprisingly confusing. Calls to love.update() added a layer of obfuscation since the standard love lifecycle is no longer utilised and everything is eventually called from love.run().

Making this change will not impact any of the examples in the documentation except the as yet unimplemented noWindow() one.

Permacomputing principle/comprehensibility

'Not doing' would result in a simpler codebase and sketch lifecycle that a new user might more readily comprehend.

I recommend we go with PR #28