Talk:Petit Computer 3/@comment-5334617-20140817020302/@comment-5334617-20140818143838

The great thing about local variables in functions is that you could write code something like:

and here will be no 'crosstalk' between the variable  in the two functions (e.g. at point A,   will have the value 10). Without local variables, before using a function, you have to know all the variables used within that function (and any function it calls, and any functions called by them...), and avoid all those variable names because their values will get corrupted. And when modifying code, you must not introduce new variables that will corrupt, or get corrupted by, other parts of the code - this is really not the kind of thing you want to deal with when you just want to make a quick fix or modify a small part of a large program.

Without local labels, before using a function, you have to know all the labels that the function uses, and avoid those label names because the program will give a  error. And when modifying code, you must not introduce a label that is used by any code called by the function, or any code that calls the function. - This is true of a program file in general, but the lack of local label declaration makes the function code dependent on the entire program file, reducing its modularity. If the designers in SmileBoom have not included local label declarations, they have ruled out the possibility of creating 'libraries' of functions, that only interact with other code in well-defined ways (e.g. parameters and return values), such that the internal details of the libraries (including the labels used) can be modified transparently to any program that uses the library.

Obviously, the second scenario is less bad. Where a label is duplicated, the system gives you the line number of the second occurrance. It can be changed, along with s,  s,  s,  s,  s,  s, and string values used as labels. The program will not even start if there is a duplicated label, so if the program starts at all, you know you do not have this problem. Where a variable name is duplicated (and not declared local), the program will start, and there is no immediate indication that there is a problem, but it may behave unexpectedly, perhaps only in rare circumstances, in ways that are very difficult to debug.

So, if they only implemented one of the two, they certainly made the right choice in making local variables. However, it would be nice to have both that and local labels. Then, in the same way you don't have to worry about what variables are used in a function before using it, you don't have to worry about what labels are used in a function before including it in your code.