Open MobsyaBot opened 6 years ago
MobsyaBot
commented
6 years ago 
Personally, I would be for adding static variables, as it is really simple to do.
Then local variables for events would be cool in order to optimize the memory, even if it seems strange to the end-user that local variables are not equally available inside subroutines. Not really a major issue to me.
MobsyaBot
commented
6 years ago 
I am not really convinced about static variables, as they are a syntactic sugar for global variables. I am afraid that it will confuse users more than help them.
I agree about local variables for events, as they really make sense on resource-constrained systems.
I think that we can live without local variables for subroutines, or allocate them globally (but that would also be a way of limiting access to global variables, and the same argument as for static variables applies).
MobsyaBot
commented
6 years ago
Ok, so let's add local variables for events when we have time :) Right now I am working on the translation of the errors from the compilator, maybe after if I finish today.
This is a reflection on local variables, anyone is welcome to join.
Local variables for events could be implemented quite easily, by extending the "temporary variables" framework. It would suffice to implement temporary variables with a life time limited to the context of the event. Two events cannot be executed at the same time, so no risk of collision. Thus these variables can be allocated at compile time.
For subroutines, things are much harder. Subroutines can be nested, thus care should be taken to allocate the "local memory" of each routine. Two options:
As a summary, it would be easy for events, but no simple solution exits for subroutines. Would it make sense to do this only for events ?
On the other side, "static" variables could also be considered for events and subroutines. In this case, they would be allocated as regular global variables, but prefixed by a specific scope. For example, "static var foo" declared in the event "myevent" would become "_event_myevent_foo" (thus hidden in Aseba Studio). This would be quite easy to do. Aseba Studio would have to be adapted in order to unhide + remove scope prefix when debugging inside a specific scope.
As a summary, static variables would be quite easy to do, for both events and subroutines, but will forever consume the space allocated to global variables.