What happens if you have multiple copies of functions like setup?

It’s quite interesting. I set up three tabs, all with setup and draw, with slightly different code in each.

Codea doesn’t freak out. Instead, it always uses the right hand tab, suggesting that it compiles from left to right and is happy to overwrite existing function definitions that are duplicated.

I can think of at least one possible use for this. Typically, tutorials involve starting simply and gradually making things more complex. It is possible to set up a series of pages, each with a different stage of the tutorial code on it (ie setup, draw etc), from simple to complex, and order them from right to left. The user can view and run each one, starting at the right, and then delete the current tab to get to the next step. The advantage of this approach is that you don’t need any extra code to tell Codea which version of setup to use, keeping things as clean and simple as possible for the user. While the user does have to delete tabs and work backwards, it may still be easier than the alternative of copying and pasting lots of bits of code from a tutorial web page.

Your assumption is correct: Codea works from left to right evaluating the tabs. Then it executes setup, and then goes into the draw loop. So the functions setup and draw that it calls are the last ones that were assigned.

Remember that everything in Codea is a pointer, so that setup is a pointer to a function. When you reassign setup then it simply repoints the pointer and there’s no complaint.

I think I’d have something a little more sophisticated with the tabs. Put each tab in an if ... end block based on some conditional which is set in the first tab. Then there’s no need to delete tabs or move them around. And if they do move them around then there’s no change in behaviour (I find with a multi-tab project that I like having the one that I’m currently working on near the front of the list to save on continually scrolling back and forth).

Yes, but then none of that code stands on its own, does it?

Anyway, I love that Codea is so forgiving…

If you look at the latest version of Cider, it takes advantage of this feature.

When you save code now, it creates an “Output” tab and writes the code to that tab. If you then stop Cider and hit run again, what you actually get is the code written to the Output tab, running as it would if in an independent project.

It’s darn handy for testing out things in a hurry.

.@Ignatz only in that the tab starts with if PROGRAM == "TutorialXYZ" then and ends with end.

You could even make it stand alone with

if not PROGRAM or PROGRAM == "TutorialXYZ" then



Then if PROGRAM is not set, it runs. If it is set then it only runs if it is equal to the tutorial name.

@Mark. A similar thought just struck me.

This feature is great for testing. If you’re building a complex project, you can just add a tab on the end with some simple test code in a setup function, and avoid having to hack the main code to run partial tests.

That is really, really cool.


Ok, this works

if Tutorial==1 then   
    function setup()
        print("Tutorial 1")
    function setup()
        print("Tutorial 2")

The problem of course is how you change that number at the top to the next tutorial number. I suppose you could ask the learner to do that.

Not quite so sure on your testability examples, but for me something more like in the physics lab where you have a currentTest and a class for each step.

That way your main can just be the basic plumbing of

function setup()
  states = {tab1(), tab2(), tab3()}  --....

function setState(newState)
  if currentState then

  currentState = states[newState]

function touched(touch)

function draw()

That’s cool too. I learn something every day.

Check out one of the demos, they used a parameter to execute tests in their code. Forgot which one it was, I think it was the physic lab.

I also use the ‘last tab standing’ rule with setup() to prototype code.

Duh, just read @spacemonkey’s post. What he said.

A nice advantage of the physics lab style is it’s good at real runtime. So imagine you have a space game with different phases of interaction, eg main menu, in space, in station, you can have classes that independantly implement setup, draw, touch etc for each state and then you have a simple way in main to flip the user from one context to another without having heavy if then else type code in your draw/touch functions.

The disadvantage of the physics lab style is that you have to use its syntax once you’ve started. The if ... then ... end method, or Ignatz’s original suggestion, makes it possible to use the same code for a new tutorial or for a completely new project. With a tutorial then you’re going to be encouraging someone to use the editor anyway so I don’t see the need for everything to be “in code”.