PropBasic: SUB/FUNC variable aliases

VonSzarvas

I am putting together my first lib of routines! Woah !

Something that niggles a little, and I think this came up a few months ago in the long PropBasic thread, is the compilation error when using the same alias name for __paramX in subroutines.

I might have:

SUB PUT_BYTE ' <index>, <byte_value>

        byteidx         VAR     __param1
        byteval         VAR     __param2

and

FUNC GET_BYTE ' <index>

        byteidx         VAR     __param1
        byteval         VAR     __param2

And of course the compiler barks that duplicate aliases have been used.

Could it be possible (and maybe useful?) for the compiler to make a first-pass and replace aliases within subs and funcs to the underlying var name (__paramX), so that multiple libraries using the same aliases can be used ?

And one step further, to replace defined actual vars (ie. byteidx VAR LONG) to a unique name to prevent conflicts. By definition, the VARS defined in a sub or func should be only for local consumption?

(I appreciate in my example I have control of the 2 matching subs, and could use slightly different alias names for each one, but when I am important many libraries - perhaps from many sources - it might go against the flexibilty of the library concept to have to rename things).

Food for thought!

Bean

Maxwin,
There is no such think as "local" variable in PropBasic. There is no stack. This is one of the things that make PropBasic so fast. And more like assembly programming too.

About the best I could do it to change the error into a warning. So the code will still compile and run, but you would need to make sure you didn't try to use the same variable in two places. Would that help ?

Bean

Heater.

Bean:

There is no such think as "local" variable in PropBasic. There is no stack.

This does not follow. You can have scope rules, local variables, in a language regardless of whether there is a stack or not.

In fact PASM itself has local variables you can have ":samename" labels in many places.

VonSzarvas

Bean,

About the simple alias declaration relating to a __paramX. I don't think that should throw any error. The alias is only "used" in the sub it is declared in - exactly the same way as the __paramX is.

SUB fromObex
result  VAR   __param2

result = __param1 >> 2
return result
ENDSUB

SUB fromMyLib
value   VAR   __param1
result   VAR   __param2

result = value + 10
return result
ENDSUB

It's a simple example, but for both subs the value of __params is only guaranteed within the sub. So if I choose to use an alias to make the sub much clearer to read, it should not throw an error just because another sub also uses the same alias names ? After all, 2 SUBs using __param1 does not throw an error?

Of course it should throw an error if there was also

result VAR LONG

defined in the COG which calls the SUB. But I think you already do that, and to confirm I am talking about alias defines, not VAR defines.

SO...

If the compiler could make a "first pass" or simple text search-replace of all code within SUB/FUNC and ENDSUB/ENDFUNC:

and rename all aliases back to the __paramX they are an alias for, ideally leaving the "friendly" alias name showing in the comments next to the pasm code in the spin file.

Then that would solve the matter and no error would be needed as no conflicts occur.


I hope I could articulate this well. I do not mean there to be local vars - only the compiler doing some pre-sanitation to help with the lib concept.

If if would help, I would gladly make up 2 simple programs indicating the before and after I tried to describe above. Please let me know!

Max.

VonSzarvas

Maxwin wrote: »

Of course it should throw an error if there was also

result VAR LONG

defined in the COG which calls the SUB.

Actually to further complicate your compiler (only slightly!)....

You could prefix those VAR definitions in SUBS with the sub name or a consecutive number generated at compile time (or both).

This would remove the need for an error if the COG which imports the SUB library also uses the same VAR name.

Although a Warning might be in order, it is likely the case that if someone declares a VAR in a SUB, it is only intended to be used in that SUB - and to declare a SUB VAR with the same name as a COG VAR would be silly ! (Or it would be an override, in which case the SUB declaration would take priority and the mentioned prefix would take care of that anyway!)

... probably this prefixing would also solve the __param alias conflicts too. You could just do it this way to make your coding simpler:

Pre-compile do a text type search/replace of all code inside SUB/ENDSUB and FUNC/ENDFUC to replace ALL VAR declarations (alias or actual) to prefix them with the sub name (and perhaps sequential number) - and also of course the code in the sub. Then in the compiled comments, the var name will still make sense (showing the prefix is probably still understandable!)

So,

SUB mySubmarine

result VAR __param1
tmp VAR LONG

tmp = result >> 2
ENDSUB

would become at pre-compile:

SUB mySubmarine

mySubmarine_result VAR __param1
mySubmarine_tmp VAR LONG

mySubmarine_tmp = mySubmarine_result >> 2
ENDSUB