New DIM/REDIM/STATIC/SHARED/COMMON/TYPE syntax (v1.5)

[FellippeHeitor]

After the topic was discussed at https://www.qb64.org/forum/index.php?topic=3182.msg124506#msg124506, this new feature has finally made it into the development build.

(Get the dev build generated on 2021-01-26, from git 35e7b22 at https://www.qb64.org/portal/development-build/)

I ask you faithful beta-testers to help me find bugs with the new syntax. With it, this:

Code: QB64: [Select]

1. DIM a AS INTEGER, b AS INTEGER, c AS INTEGER, d AS INTEGER

can be simplified into:

Code: QB64: [Select]

1. DIM AS INTEGER a, b, c, d

The same improvement is valid for REDIM, STATIC, COMMON, SHARED as variable-declaring statements. It has also been extended to TYPE. With it, this:

Code: QB64: [Select]

1. TYPE object
2.     id AS LONG
3.     value AS LONG
4.     x AS SINGLE
5.     y AS SINGLE
6.     z AS SINGLE
7.     w AS INTEGER
8.     h AS INTEGER
9. END TYPE
10.  

can be simplified into:

Code: QB64: [Select]

1. TYPE object
2.     AS LONG id, value
3.     AS SINGLE x, y, z
4.     AS INTEGER w, h
5. END TYPE

I did extensive testing locally, but you guys sure can help find approaches I didn't think of. Please let me know if any issues arise as this is the first implementation and, of course, bugs are prone to to have been introduced.

Notice that the traditional syntax remains unchanged and can co-exist with the new syntax freely.

Also, notice that when you use DIM AS type variable-list, you cannot have another AS type clause in the same line.

The new feature won't touch SUB/FUNCTION parameters.

Looking forward to getting results back from your testing.

[Pete]

Why not just...

DIM AS INTEGER a - d

That way, I don't have to type the b and the c. It would help, because I get tired after typing all of those AS UDT lines. :D

Nice addition. I'm definitely getting the 1.5 version.

Pete

[SMcNeill]

Also, notice that when you use DIM AS type variable-list, you cannot have another AS type clause in the same line.

I assume this also checks for type symbols, or would they be a problem?

DIM AS INTEGER a, b, c, d!, e#, f##

[FellippeHeitor]

Type symbols are not accepted since you begin by setting the type with the AS clause. The IDE will tell you it's not allowed.

[Pete]

Version 1.6...

From

SUB Pete (a AS INTEGER, b AS INTEGER, c AS INTEGER, d AS INTEGER)

to...

SUB Pete (AS INTEGER a, b, c, d)

If you need any help with this, CALL Pete().

[FellippeHeitor]

😂

[Pete]

Does that mean you're considering it?????

Pete

[FellippeHeitor]

I considered it humorous.

Well, jokes aside, we've gone over the exclusion of sub/function parameters in the original topic, and we're sticking with it for now.

[Pete]

Gotcha! But hey, if it weren't for those darn commas being needed as parameter separators... :D :D :D

Hey joking aside, I'm glad the modifications worked out. There are a lot of conditions that have to be checked and successfully passed to do this stuff, including the IDE work, a Steve concern, which thankfully you guys have already addressed. I do look forward to using this. In fact, I intend to retrofit it into my previous programs.

Pete