Variable scoping in Spin

David Betz

I've been working on code for the C3 lately and have ended up using bits of code from various places and am frequently faced with the problem of having to rename function parameters or local variables because they collide with the names of globals or functions in some other part of the code. Is there any reason that Spin doesn't obey the normal variable scoping rules of any other modern language? Parameter names and local variable names should have a different scope than global names. Not only does the Parallax Propeller Tool impose this restriction on same named variables in different scopes but it seems BST does the same. I'm not sure about Homespun because I haven't used it much yet. Is there any chance the Spin compilers could adopt modern scoping rules for variable names?

MagIO2

I don't see a problem with the scope rules of SPIN. If you want a local variable with function-scope, then define it behind the function. If it should have scope of one Object, then define it in VAR-section. If it should be global for all objects of the same SPIN file, define it in a DAT section. If it has to be global for different objects, then you need to use a dedicated memory location and work with it's address.

I think you only have to get used to SPIN. The idea is to put toghether code/variables in one SPIN-file that belong together and NOT do the whole project in one BIG SPIN-file.

There is little to no chance that your wish comes true. Remember, the software is for free. And my wish is that PARALLAX concentrates their manpower on Prop II development ;o)

David Betz

My problem is that this doesn't work:

VAR
  long foo
PUB fun(arg) | foo
  foo := 1

Using standard scoping rules the local 'foo' should shadow the global 'foo' but in Spin this isn't allowed and generates an error. This means that you have to avoid using any global variable names as local variables even though the scope of local variables is only within the body of a function. This doesn't make any sense and makes it difficult to adopt code that others have written if they happen to have parameters or local variables that are used as globals elsewhere in the program. This concept of locality of reference has been know for fifty years. Is there some reason it isn't supported by Spin? Does it cause some sort of special program in Spin that doesn't exist in other programming languages?

MagIO2

But the compiler complains! I'd agree with you if the compiler would not complain, because that would cause bugs which can be hard to find. But as the compiler tells you where the problem occurs it's easy to change one of the names.

What's the problem in giving different memory locations different names? Say gfoo and lfoo in your case?

For me the killer argument against your wish is that it's not a "must have" because something important is not working - it's only an "I want to have".

David Betz

I suppose it isn't a blocking bug but tt's been a standard feature of every reasonable language that has existed for the last 50 years and it is very surprising and mildly annoying that Spin got it wrong. Oh well, there are lots of cool things about the Propeller. Maybe that's why it's disappointing when a few things aren't quite up to the otherwise high standard that Parallax is known for.

Mike Green

David,
You're correct. It doesn't make sense that you can't reuse global names as local variable (or parameter) names. I don't know why Chip did variable scoping this way. On the other hand, you have to work with the tools you're given (or make your own). I could imagine BST and HomeSpun having options to allow this, but unfortunately the default would have to mirror what the Prop Tool does.

David Betz

Good point! I should write my own tools and stop complaining about the ones that already exist! :-)
This isn't really a big issue for me. I only bring it up because I've spend most of my life designing and building languages and these minor problems tend to bother me more than they ought to.

John Abshier

I agree that it is an irrritant.

John Abshier

Cluso99

FWIW: bst and homespun (Brad & Michael) were very insistent on making their compilers identical to the PropTool, all quirks included. That is why they have chosen to replicate any restrictions. From there, we have had extensions added such as #define, etc.

Phil Pilgrim (PhiPi)

I think the key to understanding the "why" is to consider the compiler's database as it's compiling an object. In its present form, it requires but a single namespace (i.e. symbol table), to which local variables can be pushed as each method is compiled, and from which they can be popped at the end. The more modern approach that David cites requires multiple namespaces that must be queried in order from local to global. I'm sure Chip weighed the advantages of each approach versus code complexity (written in x86 assembly, after all) before settling upon the current approach. And, frankly, despite the occasional annoyance, it is less prone to semantic errors due to scoping issues.

-Phil