Hi it seems a bug with DEFSTR and SPACE$...

[TempodiBasic]

Hi guys and gals

please copy this code and paste it into the QB64 IDE....

Code: QB64: [Select]

1. DEFINT I
2. DEFSTR S
3. DEFLNG L
4.  
5. SCREEN _NEWIMAGE(800, 600, 32)
6. CONST Enter = 13, Escape = 27, Space = 32
7. DIM SHARED ikey
8. DO
9.     ikey = _KEYHIT
10.     if ikey = space then print space
11.  
12. LOOP UNTIL ikey = Escape
13.  

you must get this message  of error
  [ You are not allowed to view this attachment ]  

it seems that Parser is not able to distinguish between Space and Space$ when DEFSTR S is activated.

Thanks to read

[Pete]

I think the IDE is doing its job. You used DIMSTR to indicate all variables that start with a "S" are strings. That means Space is now Space$, which is a reserved keyword. So space, if it wasn't a reserved keyword, would now be space$ and could not be equal to 32, a non-string. If what you are saying is the IDE should catch the variable space as the improper use of a keyword, well, consider this...

Code: QB64: [Select]

1. DEFSTR S
2. PRINT SPACE$(40); "a"
3. PRINT SPACE(40); "b"

By using DEFSTR, it actually accepts and runs SPACE(40) the same as the keyword SPACE$(40). So using DEFSTR makes it a keyword, and not an array!

Interesting stuff.

Pete

[bplus]

It's a wonder you don't get an error like this for CONST

Code: QB64: [Select]

1. const space = "space"

[Pete]

DIMSTR S: space = "the final frontier..."

[TempodiBasic]

Well
try this one

Code: QB64: [Select]

1. DEFSTR S
2. PRINT SPACE$(40); "a"
3. PRINT SPACE(40); "b"
4.  
5. DEFSTR I
6. DO
7.     in = INKEY
8.     IF LEN(in) > 0 THEN PRINT in, ASC(in); " ";
9. LOOP UNTIL in = CHR$(27)
10.  

....
it seems that the tokens keywords are not treated before the other tokens into the parser... so the previous instruction can affect as you can write the keyword in the code.

again this code seems to confirm that hypothesis

Code: QB64: [Select]

1. DEFSTR S
2. PRINT SPACE$(40); "a"
3. PRINT SPACE(40); "b"
4.  
5. 'DEFSTR I
6. DIM in AS STRING
7. DO
8.     in = INKEY
9.     IF LEN(in) > 0 THEN PRINT in, ASC(in); " ";
10. LOOP UNTIL in = CHR$(27)

you'll get this error
  [ You are not allowed to view this attachment ]  

[TempodiBasic]

It's a wonder you don't get an error like this for CONST

Code: QB64: [Select]

1. const space = "space"

What???
Bplus I get error!
using QB64 1.4 Stable Release from git....
  [ You are not allowed to view this attachment ]  

[TempodiBasic]

just this one and I go bed after walking with my little dog...

in the first code of #1 message
DEFSTR S doesn't activate error on the line 6 where there is Space = 32 ( a string is equal to a number) , maybe CONST is like Casablanca for testing assignment of value, free of control. In fact here no error of assignment is trilled, nor error of syntax for SPACE$ keyword!
Thanks to read

[Pete]

Sorry you haven't got any definitive answers from the developers yet, but they're busy working on my colon.

Pete

[bplus]

What???
Bplus I get error!
using QB64 1.4 Stable Release from git....
  [ You are not allowed to view this attachment ]

Yes I am saying your line #6 here should have been red-lined!

Code: QB64: [Select]

1. DEFINT I
2. DEFSTR S
3. DEFLNG L
4.  
5. SCREEN _NEWIMAGE(800, 600, 32)
6. CONST Enter = 13, Escape = 27, Space = 32  ' <<<<<<<<<<< why no error / red line?
7. DIM SHARED ikey
8. DO
9.     ikey = _KEYHIT
10.     IF ikey = space THEN PRINT space
11.  
12. LOOP UNTIL ikey = Escape
13.  
14.  

[FellippeHeitor]

Consts are processed first and only care about the content that is assigned to them. Assign it a string and it is considered a string, and hence it will conflict with SPACE$(). Assign it an integer and it will be of type INTEGER internally. Assign it a value that exceeds the limits of INTEGER and it'll be a LONG, or whatever fits the bill. Assign it a fractional number, and it'll be a SINGLE or DOUBLE, according to the total digits.

Code: QB64: [Select]

1. CONST space = 1 'space is an integer, treated like space%
2. CONST left = 3 'left is an integer, treated like left%
3. 'no conflicts with SPACE$() or LEFT$()

Code: QB64: [Select]

1. CONST space = "foo"
2. CONST left = "bar"
3. 'both are now strings, so both conflict with SPACE$() and LEFT$()
4.  

[TempodiBasic]

So we know that
1. CONST are processed before the other lines of code..
2. using the right DEFtype we can avoid to write the suffix of some keywords

see here how Parser is able to distinguish between INPUT variable and variable = INPUT(NumChars)

Code: QB64: [Select]

1. DEFSTR N, I
2. INPUT Name1
3. Name2 = INPUT$(2)
4. Name3 = INPUT(3)
5.  

This is a feature of this Parser, it can appear strange or unuseful... but it is just a feature that I have never seen before now.
Who do you know if QB45 does the same? Or is this a difference between QB45 and QB64?

And these are just some thoughts about the issue