DIM syntax from FreeBASIC

[Dav]

Chiming in a little late here, I wouldn't be bothered by seeing this DIM usage option added.

- Dav

[Bert22306]

I intensely dislike the parenthesisation approach for some reason.

The DIM AS INTEGER X, Y, Z is fine. Parser-wise it should just checking if the second element is AS, then copying the code that does the list parsing.

Hmmm. Coming from Luke, this is disconcerting. Not sure you dislike parentheses, but the advantage would be, you can put more in a single DIM statement? If you say DIM AS INTEGER, then everything in that DIM statement must be INTEGER.

I have multiple lines of DIM in many of my programs, so this idea sounds really useful to me. I was going to put that sentence in parentheses, but now I hesitate!

[FellippeHeitor]

Code: QB64: [Select]

1. DIM AS INTEGER a, b, c, AS SINGLE d, e, f

I believe the above would be valid.

[luke]

I have multiple lines of DIM in many of my programs, so this idea sounds really useful to me. I was going to put that sentence in parentheses, but now I hesitate!

What Fellippe said, though people who put too much on one line tend to have something to hide (especially those who use colons...).

Also I worked out why I don't like it, aside from the extra syntactic noise: it looks like you're declaring a tuple, not multiple separate variables.

You can't have this in function signatures because the comma becomes ambiguous:

Code: [Select]

FUNCTION f(AS INTEGER a, b, c) is c integer or single?

Ironically the parenthesised approach would be unambiguous here:

Code: [Select]

FUNCTION f((a, b) AS INTEGER, c)but I still think this looks like some kind of compound object/type.


Type declarations are unambiguous:

Code: [Select]

TYPE t
    AS INTEGER a, b, c
END TYPE

And STATIC & SHARED should follow same semantics as DIM.

[FellippeHeitor]

Life will be easier if FUNCTIONs (and by extension DECLARE LIBRARY blocks) are excluded from this.

@Dav thanks for chiming in!

[SMcNeill]

You can't have this in function signatures because the comma becomes ambiguous:

Code: [Select]

FUNCTION f(AS INTEGER a, b, c) is c integer or single?

c would be an INTEGER as it’s right of the AS INTEGER syntax, just as with a DIM statement.

DIM AS INTEGER a, b, c <— all these would be integers, so why not with the FUNCTION?

FUNCTION f(AS INTEGER a, b, AS SINGLE c) <— Wouldn’t this be the way to designate c as a single, if so desired?


Though still, I prefer the parentheses approach, just cause it’s closer to our existing syntax of TYPE after the VARIABLE.  DIM x AS type...

[FellippeHeitor]

Let's see whatever's easier to parse.

[STxAxTIC]

As Luke said (but using different words), whenever I see (a, b, c) in parentheses I see a vector, not a list of variables. Abusing parentheses for this might bite us down the road.

My main beef is in the ordering of tokens here.

This line looks normal:

Code: QB64: [Select]

1. DIM x AS INTEGER

... But this looks weird:

Code: QB64: [Select]

1. DIM AS INTEGER x, y

Because suppose I don't like "y" anymore, and delete it, then I just have:

Code: QB64: [Select]

1. DIM AS INTEGER x

Which is gonna be what, an error? Yuck. Propose this:

Code: QB64: [Select]

1. DIM x, y AS INTEGER

It looks better. On the left we have DIM, on the right we have the TYPE, and in the middle, the guts. It's especially less confusing than

Code: QB64: [Select]

1. DIM AS INTEGER a, b, c, AS SINGLE d, e, f

Disgusting.

[FellippeHeitor]

Code: QB64: [Select]

1. DIM x, y AS INTEGER

This would break compatibility with ourselves if suddenly that syntax turned x into an INTEGER, instead of a SINGLE. No deal.

[STxAxTIC]

So it won't work because it's not implemented yet. Check.

[FellippeHeitor]

Code: QB64: [Select]

1. DIM AS INTEGER a, b, c, AS SINGLE d, e, f

I believe the above would be valid.

After further discussion (have you guys not joined http://discord.qb64.org yet?), the above would not be valid, so one single AS clause per line in the new alternative syntax.

Code: QB64: [Select]

1. DIM AS INTEGER a, b, c ', etc...
2. DIM AS SINGLE d, e, f ', etc...

[Aurel]

In general i don't know DIM is used to declare/define variable it
SHOULD declare Dimension called array
so my question is why DIM is used for a simple variable?

[luke]

1) UDTs
2) OPTION _EXPLICIT

[TempodiBasic]

following Luke
3) no typing suffix
4)type of data BIT and _MEM have no suffix to declare them
http://www.qb64.org/wiki/Variable_Types

PS: Thanks to Fellippe to remember me the suffix of _BIT... ( watching at the above wiki table I have thought that the screen of my pc was dirty and that suffix was a piece of dust! LOL) so it lasts _MEM with no suffix to declare it
coding without suffix

Code: QB64: [Select]

1. DIM a AS INTEGER,  b AS DOUBLE, c AS STRING, d AS SINGLE
2. a = 10
3. d = 3.5
4. b = a/d
5. c= STR$(b)
6. _PRINTSTRING(1,1) c

coding with suffix

Code: QB64: [Select]

1. DIM a%,  b#, c$, d!
2. a% = 10
3. d! = 3.5
4. b# = a%/d!
5. c$= STR$(b)
6. _PRINTSTRING(1,1) c$
7.  

this last has an old fashion, but I must use so much SHIFT and or AltGrad on my keyboard...
let you imagine if you are working with handle of images or files, with color32bit, or memory address using _OFFSET, or big numerical data  using _INTEGER64 and _FLOAT...

[FellippeHeitor]

_BIT data suffix is `