Name of variables: an issue

[TempodiBasic]

Hi friends
about naming variable I find a little issue

the duplicating a name has a different behaviour of Parser depending from the way you do this.
Please select, copy, paste the code below into IDE

Code: (Select All)

Type XXX
    a As Integer
    b As Long
    S As String * 1
End Type

Dim Shared Xpos As XXX

Dim Xpos&

Dim Xpos as long

As you can see, you can declare an UDT and with the same name a variable with suffix (or without suffix for single type data), in the while if you try to do the same thing using the explicit type definition with AS DATATYPE you get a name alreadu used error.

In QBasic the suffix is a part of the name of the variable so Xpos$, Xpos% and Xpos# are 3 different variables, moreover an array and a variable can have the same name.
At a first glance I can suppose that a different way to manage variables with suffix and variable without it is the radix of this issue.

What is the official position about name variables following Qbasic track?

[SMcNeill]

Variable + Suffix is basically an unique being, non dependent on other definitions.

DIM x AS LONG

x! = 2.2
x$ = "foo"
x%% = 3
x~&& = 1234567890987654
x = 1234

All the above are valid and unique variables.

[TempodiBasic]

Variable + Suffix is basically an unique being, non dependent on other definitions.

DIM x AS LONG

x! = 2.2
x$ = "foo"
x%% = 3
x~&& = 1234567890987654
x = 1234

All the above are valid and unique variables.

Hi Steve
yes you're right but please try to copy and paste  this following code into the QB64 IDE

Code: (Select All)

Type XXX
    a As Integer
    b As Long
    S As String * 1
End Type

DefInt X-Z

Dim Shared Xpos As XXX

Dim Xpos(1 To 12)

Dim Xpos&

Dim Xpos as long

and please  tell me what do you think about this behaviour of parser:
DIM Xpos& doesn't trigger a name already used error, but DIM Xpos AS LONG does it!
So I must think that Xpos& and Xpos AS LONG are 2 different LONG variables, isn't it?
Thanks for feedback!

[SMcNeill]

DIM basically sets what your unsuffixed type is going to be.

Xpos& has a suffix. It's not affected by your DIM.

Dim Shared Xpos As XXX <--- here, you define your unsuffixed type to be an XXX-type

Dim Xpos as long <-- here, you try to define your unsuffixed type to be a LONG, but it tosses an error. You've already refined your unsuffixed type above.

If you like, think of them as:

x% -- integer
x& -- long
x! -- single
x# -- double
x$ -- string
x(nothing) -- Defaults to same as default variable type, unless you DIM it, then it's that type. Once DIMMED, you can't DIM it a different type.

Think of that x(nothing) as being an unique, one-define only shortcut type. Once you set it, you can't just unset it and retype it at the drop of a hat. %&!#$-types are all explicitly defined, and as such, they're not necessarily the same as your (nothing) type. (Though they can be...)

Code: (Select All)

Dim x As Long 'this basically just creates a shortcut defining x as being the same as x&
x& = 123
Print x

The above says that x(no sufffix) is going to be a shortcut for x&. That shortcut is now defined, and you can't define it again easily, without getting that DUPLICATE DEFINITION ERROR.

[TempodiBasic]

Hi Steve
Thank's so much,
your  explanation and your vision about why unsuffix_name_variable into a DIM declaration can arise a Duplicate Definition Error while the same variable declared by suffix doesn't arise that error. are very fascinating.
Moreover this kind of issue (how manage duplicate names of variables) is different between QB64 and Qb4.5.
I must be clear, there is no error but only a difference of rules between QB64 and QB4.5
We doesn't matter about it just because we write in QB64 for compiling in QB64 and not for compiling  in QB4.5!

[TDarcos]

Well, there is one possibility, the command

OPTION _UNIQUE

Which means you can't use two variables of the same name regardless of type. Once a variable is used or defined it can't be reused as a different type, and you can't use the same name for a scalar or array. You also can't use the type specification symbol once DIMed.

Not sure if there is much interest in such a feature, but I think it would help reduce error. And those who don't want this protection don't have to use it.

[mnrvovrfc]

Well, there is one possibility, the command

OPTION _UNIQUE

Nope, because some people right now depend on "a$" being different from "a AS UDT" or something like that. The QB64 source code might feature it.

There's no need for it anyway because it has to do with using type sigils, or not using them. If you define a variable without sigil, such as "a AS UDT" then the compiler strictly expects it to be that type always, but would treat "a$", "a&&" and other "variations" of variable called "a" differently. QB64 was purposely designed like that. The "default" mode of Freebasic doesn't really offer the choice, whether or not to have variable name "duplicates". Only for string functions like "STR$()" it could ignore the dollar sign but a string variable might not be allowed to carry any sigil. It should be the same in "lang qb" mode as in QB64.

[mnrvovrfc]

I must add that the discussion above always applies in global scope. Within subprograms one has to be careful with using "global" variables, ie. those defined as "DIM SHARED" near the top of the source code, or declared as "SHARED" within the subprogram. Those could suddenly throw up an "Duplicate definition" or "Name already in use" (geez I despise this last one) when it has to do with global variables to be used inside subprograms. Otherwise "DIM x AS INTEGER", "DIM x AS _MEM" etc. could be freely implemented in subprograms kept separate from one another, and especially those found in "$INCLUDE'd" files.

Once there is a "DIM SHARED x AS LONG" before any subprogram cannot "re-type" "x" to anything else unless it's "x$" or other type which is not UDT (and in this example only, except "x&").

[TDarcos]

OPTION _UNIQUE

Nope, because some people right now depend on "a$" being different from "a AS UDT" or something like that. The QB64 source code might feature it.

Excuse me, and I am trying to understand something. You are saying it's not a good idea because people may be depending on use of the same variable name in different data types, e.g. using both a% and A$, Yes, I can understand, we can't add a feature that breaks compatibility with existing programs; I get it, and it makes sense, What I am trying to understand is how does a new feature not used in a program affect  that program? If you knew about it but didn't use it or didn't know about it, the exact same behavior happens: nothing. Remember, I suggested it as an optional feature, that someone who wants this feature as a means to protect from collision errors (using the same variable for different purposes, or thinking one variable is the same as a different one because the base name is the same). Most languages do not allow reuse of a named variable for a different purpose in the same scope.

It's not that I thought it was all that important, just a way for someone who wants to use it, and by making it optional, those who want the extra protection could use it.

[mnrvovrfc]

I don't remember if QB/QBasic/PDS allowed "a%" and "a&", or "a%" and "a$" in the same source code module. Basically what you're asking for is to throw an error in that case which is not going to sit well with people using QB64 largely because of this quirk, and otherwise preferring to use some other programming system. Some people try to type the least possible whether it's a computer program or a resume or an inventory list. They've praised C++ because it's possible somehow to have multiple variables just called "A" or "a", like in an obfuscation example I discovered somewhere inside MSDN many years ago. Some people don't appreciate "protection". What you're requesting is going to affect function definitions as well; the request is cannot have sigils to set the function return type and instead make it look like Freebasic and Visual Basic.