DIM - AS - VARIABLE TYPE likely bug

[SMcNeill]

but we incur into a "Name already in use" error if we write:

DIM A AS INTEGER
DIM A AS STRING

ah, there is no suffix for qb64 to tell the differenece between the 2 a's

this lets you define everything as a type unless you explicitly say something different
DefInt A-Z
Dim A As String

I have understood. 
IMO, QB could have been programmed in a way in which the suffix of the varible "A" definied with "DIM A AS INTEGER" was "%", as it is in the case of "DIM A%", considered that in both the ways we define exactly the same variabile. But QB is conceived so that we can have:
DIM A%
DIM A!
DIM A$
DIM A&
etc,
but we cannot have
DIM A AS INTEGER
DIM A AS SINGLE
DIM A AS STRING
DIM A AS LONG
etc.


The only reason I found for this, is that if we use "AS" instead of the suffixes, then in the code is possible to use variable name without having to add the suffix each time and, in order to be able to do that, only one "A" must be allowed.

But finally, even if at first this could seem a simplification, actually I prefer to use suffixes for 2 reasons:
1. We could have variables that actually are exactly the same thing and therefore should have the same name. For example a coordinate X, that it is integer(%) or single(!) depending if we are on a view port coordinate or in physical screen coordinate. So, using (AS) it will be compulsory to use different variable name, but I don't find anything clearer than the possibility of using X% and X!;

2. I find that presence of the suffixes actually makes the code more readable.

So, I think is preferable to DIM variables and arrays with suffixes, avoiding the use of AS.

QB is conveieved so that you can have a shortcut and reduce repetitive typing injuries to yourself.

There is absolutely nothing stopping you from doing the following:

DIM A AS INTEGER
DIM A!, A#, A%%

Now, there is absolutely nothing stopping you from using A, A%, A!, A#, and A%% all in your program.

Code: (Select All)

Dim a As Integer

Dim a!, a#, a%%



a% = 1

a! = 2

a# = 3

a%% = 4



Print a%

Print a!

Print a#

Print a%%



Print

Print

Print a

No issues whatsoever with the above.  All are DIMMED.  All are usable.

The only thing that DIM A AS INTEGER is, is telling the compiler that A -- without any suffix -- is going to be an integer and thus represent the same thing as A%, saving you the need to type that % symbol everytime you use A alone.

And A, with no suffix, can't be INTEGER, SINGLE, DOUBLE, BYTE all at the same time!!  It can only be one of them.  By default, it's SINGLE.  By using a DIM, you make it whatever you want.

That's all there is to it!

[bartok]

@bartok - I don't want to offend you, but are you sure that programming is right for you?
I have now looked at your questions and comments, and in my opinion, since 2022 until today, you haven't understood that programming has nothing to do with philosophical considerations.

Sometimes to chose a solution rather then an other could be a philosofical issue, but sometimes is not.

https://qb64phoenix.com/forum/showthread...ght=bartok
My humble recommendation: Buy a book about what programming means, such as: Code Complete, Version 1

The standard work on programming

Thank's you for answering here to an other topic written elsewhere, with an aswer that would have been OT even if answered there. Programming is not my work. However, its your opinion that programming has nothing to do with philosophical considerations.

ah, there is no suffix for qb64 to tell the differenece between the 2 a's
this lets you define everything as a type unless you explicitly say something different
DefInt A-Z
Dim A As String

I have understood. 
IMO, QB could have been programmed in a way in which the suffix of the varible "A" definied with "DIM A AS INTEGER" was "%", as it is in the case of "DIM A%", considered that in both the ways we define exactly the same variabile. But QB is conceived so that we can have:
DIM A%
DIM A!
DIM A$
DIM A&
etc,
but we cannot have
DIM A AS INTEGER
DIM A AS SINGLE
DIM A AS STRING
DIM A AS LONG
etc.
The only reason I found for this, is that if we use "AS" instead of the suffixes, then in the code is possible to use variable name without having to add the suffix each time and, in order to be able to do that, only one "A" must be allowed.
But finally, even if at first this could seem a simplification, actually I prefer to use suffixes for 2 reasons:
1. We could have variables that actually are exactly the same thing and therefore should have the same name. For example a coordinate X, that it is integer(%) or single(!) depending if we are on a view port coordinate or in physical screen coordinate. So, using (AS) it will be compulsory to use different variable name, but I don't find anything clearer than the possibility of using X% and X!;
2. I find that presence of the suffixes actually makes the code more readable.
So, I think is preferable to DIM variables and arrays with suffixes, avoiding the use of AS.

QB is conveieved so that you can have a shortcut and reduce repetitive typing injuries to yourself.
There is absolutely nothing stopping you from doing the following:
DIM A AS INTEGER
DIM A!, A#, A%%
Now, there is absolutely nothing stopping you from using A, A%, A!, A#, and A%% all in your program.

Code: (Select All)

Dim a As Integer

Dim a!, a#, a%%

a% = 1

a! = 2

a# = 3

a%% = 4

Print a%

Print a!

Print a#

Print a%%

Print

Print

Print a

No issues whatsoever with the above.  All are DIMMED.  All are usable.
The only thing that DIM A AS INTEGER is, is telling the compiler that A -- without any suffix -- is going to be an integer and thus represent the same thing as A%, saving you the need to type that % symbol everytime you use A alone.
And A, with no suffix, can't be INTEGER, SINGLE, DOUBLE, BYTE all at the same time!!  It can only be one of them.  By default, it's SINGLE.  By using a DIM, you make it whatever you want.
That's all there is to it!

ok, but in this way I will have a code with variables with both suffixes like $, %, &, etc and variables names without suffixes: IMO this make the code less clear, because who reads the code could find an "A" and an "A%" and it is intuitive to think that they are not the same variable. In the way you said, I could also have a code with only variables with suffixes. But IMO, this is "philosophically" inelegant: to me, variables have to be DIMmed using OR the suffixes, OR using "AS". Of course, everybody is free to do what he wants to, but IMO, there are no reasons to DIM variables with "AS" if the programmer has not the intention to use the consequent faculty of writing the code without using suffexes each time, considered that in this way is not possible to have more then one "A". So, I prefer to DIM variebles with suffexes and to have a code with variables where the suffix is speciefied each time, because I think that in this way is much clearer to be read. What these considerations are, if not philosophical one? I write the code thinking about that does exist in the world someone crazy enough to read it, so I try to improuve the clarity and to avoid redundancies, waste of memory, etc. This bring to some questions about HOW to do things that could be done in much than one way. A banal example: if in a program the user can exit in many parts, then it is possible to the go to SYSTEM in many parts of the code. To me, it is forbidden: I admit ONLY one SYSTEM and the program must ends only there, after having exited ALL subroutines, routines and SELECTs, FORs, DO LOOPs cycles, etc. I must chose a way and then use only that way. These are philosophical "issues" and they affect my own decisions, but my original post was about a thing that I didn't know, considered that I thought that writing DIM A AS INTEGER was the same thing then writing DIM A% and it is not true, because if I use (only) "AS" I can't have more then one "A".

[bplus]

i repeat again, you don't ever have to DIM a%, you can just start using it, whats more elegant than that?

i remind also A is a one symbol varaible name and A% is a two symbol variable you seem to be conflating the two different names, by your @bartok 'philosophy' you'd never use a one symbol variable name and thats fine if you like typing all those suffixes.

ps i like bringing philosophy into coding style mainly because KP doesn't ha, ha.

also i remind the hobgoblin effect of foolish consistencies.

[bartok]

i repeat again, you don't ever have to DIM a%, you can just start using it, whats more elegant than that?

i remind also A is a one symbol varaible name and A% is a two symbol variable you seem to be conflating the two different names, by your @bartok 'philosophy' you'd never use a one symbol variable name and thats fine if you like typing all those suffixes.

ps i like bringing philosophy into coding style mainly because KP doesn't ha, ha.

also i remind the hobgoblin effect of foolish consistencies.

I know that I don't have to DIM X% and that I can just start using it, but I don't like to do like that: I don't consider this elegant, because it is less tidy and therefore, less elegant: this is my "philosopy". So, I like to use OPTION _EXPLICIT, declaring all the variables and using only one way to do that: with suffixes, or with "AS". So, is it true or not, that if I DIM variables with "AS", I can't do:
DIM X AS INTEGER
DIM X AS SINGLE
?

So, considered that, as said, I want to declare all the variables only in one way, is it true or not, that I can do only:
DIM X%
DIM X!
?

because I don't want to do neither:
DIM X AS INTEGER
DIM X!
and then
X = 39 (or X% = 39)
X! = PMAP(X, 2) (or X! = PMAP(X%, 2))

nor directly, without declaration:
X% = 39
X! = PMAP(X%, 2)

So, what's the problem? I don't like to use a one symbol name. My original post was intended only to understand why I had an error with:
DIM X AS INTEGER
DIM X AS SINGLE

once understood that QB is conceived like that and therefore DIMing variables with "AS" allow, if wanted, to use in the code variables without suffixes, the question is closed for me. The rest of the things are my personal choices of coding which were not the subject of my question. I didn't ask if my code is more beautiful if I write DIM X% rather then DIM X AS INTEGER or if Aristotele would appreciate much a more a direct X%=39 without variable declaration.

[SMcNeill]

Here's a question:  What happens when you do the following?

X = 1
X = 2
X = 3
?

Is X now 1, 2, 3?

Of course not!!  One variable can NOT contain three different values in it.  Things just don't work like that.  One value overwrites another, and the variable is only the last value.

---

Now, what happens when you try the following?

DIM X AS LONG
DIM X AS SINGLE
DIM X AS STRING

Is X now a LONG, SINGLE, STRING?

Of course not!!  One variable can only be one type at a time.  If it wasn't, how the hell would you ever work with it??

x = "a"
x = "a" + 1

Now, what the heck is x??  Is it "a1"?  Is it "a" + chr$(1)?  If it "b"?

Who knows!!  It might be milk and cookies and snuggles and rainbows, in some insane guy's philosophy.  I can tell you what it is in BASIC however -- and we're talking any basic here:  IT'S AN ERROR!!

Variable types don't work that way.  Never have.  Never will.

IF you like suffixes, then use suffixes.  There is absolutely NOTHING stopping you from going apeshit crazy and using the same variable name for everything in your code -- including labels and such as well, if you're insane enough to do so.

Code: (Select All)

Dim a%, a$, a!, a%%, a$1



a% = 1

a$ = "two"

a! = 3.4

a%% = 4

a$1 = "5"

GoSub a



End



a:

Print a%, a$, a!, a%%, a$1

Return

There's just certain rules of syntax that are non-negotiable.  

You can't redefine CONSTS.
CONST a = 3
CONST a = 5 'ERROR!! ERROR!!

You can't assign a variable to be more than a single type.
DIM a AS LONG
DIM a AS SINGLE 'ERROR!! ERROR!!!

It just doesn't work.  Never has.  Never will.

If that's not acceptable, then you'll probably want to find some other programming language to work in that's more user-friendly for you.  Maybe try Java.

[CharlieJV]

I have found a probable bug using AS.

Writing, for example:

DIM A%

it's the same then writing

DIM A AS INTEGER

But it is possible to write:

DIM A%
DIM A$

but we incur into a "Name already in use" error if we write:

DIM A AS INTEGER
DIM A AS STRING

Example:

Code: (Select All)

OPTION _EXPLICIT

DIM A$

DIM A% '--------------------------> working



'DIM A AS STRING

'DIM A AS INTEGER'  ---------------------> not working



A$ = "hello"

A% = 2



PRINT A$, A%

I'm not sure if this is useful, but one gets no points by not trying ...

In early BASIC implementations, we didn't declare variables.  Variables would be created upon assignment of a value to them.  (LET A$ = "howdy")

When assigning a string literal to a variable, that variable had to have a $ suffix, indicating the type of the variable before the literal value got assigned to it.

Referencing the GW-BASIC Constants and Variables chapter: a % suffix for integers, a ! suffix for single-precision floating point numbers, and # for double-precision floating point numbers.  

If the variable has no data type suffix, then it is treated as a single-precision floating point number.

The data type suffixes are part of the variable name.  If you have "LET A = 5.1" and "LET A! = 5.1", these are two independent variables, because their names are not the same.  One name is "A", the other is "A!".

Back in the day, DIM was only used for declaring the dimensions of an array, and that was only required for arrays with subscript values greater than 10.

Array names, just like variables, included a data type suffix (I prefer to say data type sigil) to define the data type.  No data type suffix, the array is then treated to hold single-precision floating point numbers.

At some point (QBASIC?), BASIC implementations started using DIM to also declare variables, with the option of using the "AS data_type" clause (allowing the riddance of those "pesky" data type suffixes).  I think this was an enhancement added part and parcel with features for structured programming (line numbers no longer required, multi-line functions, "SUB" subroutines, etc.)

However, for compatibility with previous BASIC implementations, the data type suffixes still work.

In the structured BASIC implementations, a variable referenced as A% is a variable distinct from variable "A" declared with "DIM A AS INTEGER", because the variable name "A%" is not the same as the variable name "A".

Myself being a little bit old school, I still prefer variable (and constant/array) names with data type suffixes.  Although variables don't have to be declared when using suffixes, I like the idea of declaring all variables before the program's code.  So DIM A$.

For me, there's no philosophical debate about it.  It is a design-decision based on what works for my brain, everybody else can take my code or leave it.

If a project is really interesting to me (and/or I'm getting paid to contribute), I'll adopt whatever standard is best for that project and the people leading it (so I'm quite happy to toss my preferences aside.)

[SMcNeill]

In the structured BASIC implementations, a variable referenced as A% is a variable distinct from variable "A" declared with "DIM A AS INTEGER", because the variable name "A%" is not the same as the variable name "A".

Go back and try it again in QB45 and previous versions of BASIC.

DIM a AS INTEGER
a% = 1
PRINT a

This will print the value of 1, as "a" is referencing the variable named "a", that is an INTEGER, while a% is *also* referencing the variable named "a" that is an INTEGER. In this case, "a%" is the same variable as "a".

In BASIC, variables are broken down into two distinct identifiers -- variable name and variable type.

a% is the variable a, which is an integer.
a! is the variable a, which is a single.

a -- without any suffix -- is a shortcut for whatever type it currently is working with.

Code: (Select All)

a% = 1

a! = 2.2

a$ = "cat"



Print a 'default is SINGLE, so this is 2.2



DefInt A



Print a 'default is now INTEGER, so a is now a% or 1



DefStr A



Print a 'default is now string, so a is now a$, or "cat"

Now, how does DIM play into all this?

DIM defines the variable-with-no-suffix as one specific type, sets that type, and it is forevermore that type. Changing the default type does nothing to change what that variable-with-no-suffix is. DIM a AS LONG, and a is forevermore a LONG, no matter if you DEFINT, DEFSTR, DEFLNG, or whatever!

But here's the deal at the end of the day:

1) A variable name can be used with *ALL* variable types, as long as you manually specify the suffix with that variable.
2) DIM variable name AS type, is just a shortcut to say, "this name is always going to be this type", so you don't have to type that suffix.
3) There is ZERO difference in the variable-without-a-suffix and the variable-with-a-suffix-of-the-same-type.
4) If you're crazy, feel free to use every variable with the same name and with different types, if you want to. Just don't forget the suffix, or to swap DEF types as wanted until you obfusicate your code into meaningless drivel that nobody would ever want to read/work on.

[bplus]

+1 Interesting, i did not know dim locks in type for variable so you can unambiguously use the letters only name (without sigils).

[bartok]

Here's a question:  What happens when you do the following?

X = 1
X = 2
X = 3
?

Is X now 1, 2, 3?

Of course not!!  One variable can NOT contain three different values in it.  Things just don't work like that.  One value overwrites another, and the variable is only the last value.

---

Now, what happens when you try the following?

DIM X AS LONG
DIM X AS SINGLE
DIM X AS STRING

Is X now a LONG, SINGLE, STRING?

Of course not!!  One variable can only be one type at a time.  If it wasn't, how the hell would you ever work with it??

x = "a"
x = "a" + 1

Now, what the heck is x??  Is it "a1"?  Is it "a" + chr$(1)?  If it "b"?

Who knows!!  It might be milk and cookies and snuggles and rainbows, in some insane guy's philosophy.  I can tell you what it is in BASIC however -- and we're talking any basic here:  IT'S AN ERROR!!

Variable types don't work that way.  Never have.  Never will.

IF you like suffixes, then use suffixes.  There is absolutely NOTHING stopping you from going apeshit crazy and using the same variable name for everything in your code -- including labels and such as well, if you're insane enough to do so.

Code: (Select All)

Dim a%, a$, a!, a%%, a$1



a% = 1

a$ = "two"

a! = 3.4

a%% = 4

a$1 = "5"

GoSub a



End



a:

Print a%, a$, a!, a%%, a$1

Return

There's just certain rules of syntax that are non-negotiable.  

You can't redefine CONSTS.
CONST a = 3
CONST a = 5 'ERROR!! ERROR!!

You can't assign a variable to be more than a single type.
DIM a AS LONG
DIM a AS SINGLE 'ERROR!! ERROR!!!

It just doesn't work.  Never has.  Never will.

If that's not acceptable, then you'll probably want to find some other programming language to work in that's more user-friendly for you.  Maybe try Java.

I'm getting quite angry.
You (plural) are answering to questions that I have never asked, starting from a message totally OT, when the question for me was already CLOSED.

I repeat again.
Considered that

DIM X AS INTEGER is the same that DIM X%
demostrated from the fact that:
DIM X AS INTEGER
X = 5
PRINT X%

returns "5"

and considered that I can write

DIM X%
DIM X$

I asked WHY I can't write:

DIM X AS INTEGER
DIM X AS STRING
hypothesizing a bug.

PERIOD.

Once having undestood WHY is not a bug and WHY is not possible to do so, for me the question was CLOSED LONG TIME AGO.

I don't have never asked nothing about philosophies, I don't have never said that I am against the fact that I can't write:
DIM X AS LONG
DIM X AS SINGLE
DIM X AS STRING

What the hell does that:

X = 1
X = 2
X = 3
?

Is X now 1, 2, 3?

I know from the age of 5 that X=3, and that the variable can't have 3 values at the same time.

[Dimster]

Hi bartok .. thanks very much for asking this question. I do understand you are feeling somewhat under attack personally and I completely see where you did get a satisfying answer to your query but the subject took on a life of it's own after that point. Your question has highlighted some of the issues I have will my approach to variable names and types. I dim everything and and often get tripped up with string variables. If, at the beginning of my code I have something like Dim Shared  A AS String, days later and multiple lines later I'll run into a situation where I have 

Print B
Print C
Print A
Print D

And I'll forget that A is printing a string value because it looks like it's the same type as the others.

Where strings are concerned I'm now in the habit of A$ as it pops out

Print B
Print C
Print A$
Print D

 Hope you may see the comments here as addressing the issue "DIM - AS - VARIABLE TYPE likely bug" and not bartok personally.