DIM syntax from FreeBASIC

[FellippeHeitor]

How outraged would the community be if we borrowed the alternative syntax of DIM from FreeBASIC, so that instead of:

Code: QB64: [Select]

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

we could:

Code: FreeBasic: [Select]

1. DIM AS INTEGER a, b, c

As per https://www.freebasic.net/wiki/KeyPgDim

Note that there's nothing being developed in that direction, but it's something that's been in my mind for a while now.

Also notice that it wouldn't be incompatible with former programs, since the existing syntax would remain untouched.

Also notice that both syntaxes can co-exist.

Also notice I haven't checked our DIM parser for the feasibility yet, so this could all be hypothetical in the end.

Let me hear from y'all.

[bplus]

@FellippeHeitor   I would love that! I wish I could do that about every time I start using OPTION _EXPLICIT

EDIT the rest:

Never mind I just looked at your syntax again ;-))

[RhoSigma]

I guess many people will love it, cause it saves a lot of keystrokes if somebody wanna go the "written" type way. For me personally it won't make any difference, as I'm a hardcore type suffix user.

Code: QB64: [Select]

1. DIM a%, b%, c%
2. 'or even different types in the same DIM line
3. DIM i%, l&, s!, d#, t$

[bplus]

Yeah, if it doesn't make old code bad, steal away!

[Dimster]

I'm not familiar with FreeBasic and your link to same did answer my thoughts on SHARED but I can't seem to find REDIM in FreeBasic. Do you think there could be an issue with Re dimming a FreeBasic Dim'd variable?

[FellippeHeitor]

No issue at all.

[SMcNeill]

I’ve always thought something similar would be nice, but I think it could be a little closer to our existing syntax to use with a few parentheses.

Instead of:

DIM AS INTEGER a, b, c

How about:

DIM (a, b, c) AS INTEGER, (d, e, f(10)) AS SINGLE

You’d basically define blocks of variables, delimited by parentheses, all as an unique variable type.

[FellippeHeitor]

It'd work too. Whichever would be easier to parse internally, really.

[SpriggsySpriggs]

Sure! I don't see any problem with that.

[Dimster]

It's ok I found Redim info in FreeBasic

[Petr]

I'm also for.

[FellippeHeitor]

True!

[Bert22306]

I don't know if there's an advantage to create a syntax exactly like FreeBasic's, or more similar to C, because otherwise, Steve's idea would be easier to adapt to.

DIM (a, b, c) as _FLOAT, (d, e, f) as DOUBLE

Also DIM SHARED, of course, same way.

It's more like what we do now, but without all the repetition. Yes, this seems like a useful improvement to me too.

[johnno56]

I think that the change makes 'Dim' simpler to use. My only niggling concern would be, are the changes being made to make QB64 more efficient or to make QB64 more like FreeBasic? Just a thought...

[TempodiBasic]

Hi
this kind of perspective to let more easyness to type is powerful!
With Steve's structure maybe that it is easy to manage the syntax by Parser.

At first time to avoid these writing  I used to put suffix to variables
but with new QB64 types I  don't like mystyping the suffix  like for example  an _UNSIGNED LONG  becomes a LONG
so I have put in working the keyword  DEFINT DEFSTR DEFDBL DEFSNG...and in this direction there are the keyword of expansion _DEFINE! This solves with a workaround and limiting the firstletterofVariable.

This C like and Pascal like feature can be interesting, but is it  expanded to the parameter of the SUB/FUNCTION or there we must type type type like we do now?